History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: SRC-171
Type: New Feature New Feature
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Dan Fabulich
Reporter: Dan Fabulich
Votes: 3
Watchers: 4
Operations

If you were logged in you would be able to see more operations.
Selenium Remote Control

Allow users to pass more complex options to browser launchers

Created: 07/Nov/06 10:49 PM   Updated: 08/Mar/09 11:29 PM
Component/s: Server, Client Driver - Java, Client Driver - .NET, Client Driver - Python, Client Driver - Ruby, Launcher - Firefox, Launcher - Internet Explorer, Client Driver - Perl, Launcher - Opera, Proxy Injection, Launcher - Konqueror, Launcher - Safari
Affects Version/s: None
Fix Version/s: 1.0


 Description  « Hide
As described here: http://forums.openqa.org/thread.jspa?threadID=5124

We should extend getNewBrowserSession (and thereby the DefaultSelenium constructor in all of the clients) to optionally take an additional argument, where you could specify additional options. Here's some stuff I could imagine people wanting to specify, and how they'd specify it:

&1=*iexplore&2=http://x&3=proxyInjectionMode
(would allow us to get rid of *piiexplore)

&1=*iexplore&2=http://x&3=multiWindow
(no explicit need for the command-line argument)

&1=*iexplore&2=http://x&3=proxyInjectionMode,port:4445
(would allow us to open new ports for PI mode at session launch time, allowing us to support multiple sessions in PI mode)

&1=*iexplore&2=http://x&3=mshta
&1=*firefox&2=http://x&3=chrome
(MSHTA and Chrome are just modes of using IE and Firefox... why call them different browsers?)

And we can always combine options:

&1=*firefox&2=http://x&3=chrome,profileTemplate:c:\blah

I'd still want to support the old names/modes for backwards compatibility, but this seems like a good idea to me.

Oh, and, while we're at it, maybe get rid of the "*"?

(The star is really there for historical reasons. If you omitted the star, we used to assume you meant to use a custom browser, but we quickly learned that was confusing ["firefox" means run firefox from the path directly without modifying it, whereas "*firefox" means use logic to calculate the firefox location and modify its profile heavily]. It was clearly the right decision to demand that you call it "custom" if you wanted to use a custom browser.)

If we did remove the star, we might even want to do this:

&1=firefox&2=http://x&3=executable:c:\blah\firefox.exe



 All   Comments   Change History      Sort Order:
Philippe Hanrigou - 20/Feb/08 01:31 AM
I like the idea of extending getNewBrowserSession with optional options. Selenium Grid could leverage this to target specific environments
(http://selenium-grid.openqa.org/how_it_works.html#requesting-a-specific-environment)

On the other end I am not especially fond of the proposed mechanism as the parsing of these options requires knowing about them ahead of time. If a user wants to define a custom defined environment "IE on Windows XP SP2 - Opteron" parsing '&1=*ie&2=IE%20on%20Windows%20XP%20SP2 is impractical

Having the opportunity to name the options and have Selenium RC ignore them if they are not recognized seems a lot more extensible: Ideally

&1=ie&env=E%20on%20Windows%20XP%20SP2

I realize that this is not consistent with current way of handling Selenese with rely on sole order to parse the parameters. A degraded form could be:

1=ie&2=env:ie%20on%20windows%20xp%20sp2

What do you think?


Dan Fabulich - 05/Jan/09 01:29 PM
Targeted for 1.0 tentatively. This would allow people to workaround SEL-587.

Dan Fabulich - 08/Mar/09 11:29 PM
Hopefully finished in RC revision 2624. Still not able to really control PI mode via options (that's SRC-627) and there's absolutely no documentation for it or static type support available on the Java/C# side, but it knda sorta works.