Erik's previous link to the Microsoft web site shows the incompatibility

that some of our tests have with HTA mode - certain tests are using location

properties that are not accessible in HTA mode.  These tests will never be

able to use HTA until they are changed, which, given their quantity, will be

quite a while from now.

You bring up an interesting alternative with the addBrowserLauncher.  We

will look into it.

I look forward to Dan and Phillipe returning, but here's the part I don't

get.  You have a Map, with two distinct keys pointing to the same value,

with that being the case because you want to drive users towards a more

stable model.  I understand the goal behind this, and I understand the

sentiment of not maintaining backwards compatibility with respect to the API

of the clients (signature/parameter changes, etc.).  However -- given that

you have existing users, many of whom require the original *iexplore

behavior because of their use of javascript identifiers that Microsoft,

not you, have said are inaccessible in that mode, making this particular

change go beyond the API compatibility question.

If *iehta mode were compatible with javascript in *iexplore, I would not

have a problem with this.  We'd accept the change and eventually, without

such an immediate need, modify our launchers to say "*iehta" for better

readability and understandability in what was being launched.  That is not

the case, though. They are not compatible, and by changing the mapping we

force users to make the decision to either upgrade RC or change user-side

code.  This is not an easy choice for us: we want to upgrade, rather

emphatically, but the change required is significant.  Not all of our

Selenium testers use the Selenium Farm here.  If that were the case, then

either of the two methods proposed as a workaround would be much easier to

manage, but as it is we are guaranteed to cause some tests to fail during

the transition on the Farm, with a much longer tail of failing tests as

other users have to stop what they are doing and make the same change.

I agree with Paul in that if you want new users to have the easiest and

smoothest experience with Selenium and IE, that the documentation say that

*iehta is preferable to *iexplore, much as and for similar reasons as

*chrome is preferable to *firefox.  Specifically call out the three location

properties Erik mentions as being an incompatibility for *iehta.  Then let

the users pick what they need to use.  Using dual distinct keys to map to

the same value decreases understandability as well, because given a launcher

"*iehta", and "iexplore", I'd only have expected the first one to launch in

HTA mode.

I don't think we necessarily should remove the entire code branch from the

change that made the mapping - as I understand it, several of those were

fixes that would be a good idea anyway.

We don't want to have an internal version of Selenium used on the Farm.

We've tried that, back when we first started using it, and merging was a

royal pain in the rear.  We'd much prefer to use a vanilla version, because

that way, our users who do not use the Farm can write their tests and then

have them just work when they are automated to the Farm.

I suppose, the gist of this email is that the change where *iexplore

launches IE in HTA mode is beyond the normal considerations of 'backwards

compatibility', because it is not the rest of the Selenium code that breaks

compatibility -- it's a basic, low-level property of HTA mode itself that is

incompatible.  I've upgraded Selenium several times prior to this, changes

which included signature changes that we could not hide using reflection,

and none of those were as difficult as this upgrade is going to be,

regardless of which of the two options presented are used.

Thanks for listening, /rant.

-Jen

Hi all,

I'm glad to hear that you think that this can be solved by a bug fix.  I

would like to clarify one thing.

We do not have a problem with HTA being the "default" mode.  Our issue was

in how "default" seems to have been implemented, because our tests are no

longer getting what we ask for.  The Farm actually does handle tests that

want HTA mode via the *iehta mapping.  Because Googlers were such quick

adopters over a year ago, however, HTA mode was not stable enough at that

time, so many of them worked within the constraints and limitations of

*iexplore.

Thank you for the workaround suggestion, but we cannot upgrade when it

requires changing the tests: every one of our Selenium-using projects has a

different schedule and requirements and cannot be retasked to do a code

scrub for the purposes of upgrading.  We similarly are unwilling to, on the

fly, replace "getEval" with "runScript", for the same reason as above: we

must give people what they ask for.

That said: will we encourage our Selenium users to change their tests to

make them better able to take advantage of improvements in Selenium?  Of

course.  What we cannot do is impose when they do this.

One more clarification: the *iexploreproxy change is feasible for users of

the Selenium Farm, although it will not go unnoticed by the continuous

integration systems.  The reason that is not a simple workaround is because

Google also has many Selenium testers who do not use the Farm, and each and

every project in that category will have to make a similar change.

The only "easy" workaround we actually have is the one where we replace the

mapping of *iexplore to the original browser launcher, either by modifying

the code or surrounding the vanilla RC jar with one that includes the

wrapper that Pat suggested.  I will strongly regret making either of these

choices, because they represent an inability to use "off the shelf"

Selenium.

Again, I am glad to hear that you think that the primary means of

incompatibility that we have found with the *iexplore -> HTA mapping is

something that can be fixed in Core.  When do you think that would be able

to be done?  If it is not in the next week, we will have to go with a

branched version until it is in place.

While it's true that I may still "grumble" about not getting what I asked

for with *iexplore, if there are truly no incompatibilities between HTA and

pre-2450 modes,  then I will certainly keep it to myself :).

-Jen

Yes - Thank you, Haw-Bin, for more clearly stating my concerns :).

-Jen

This mode-based approach would work for Google.  It would give us the

ability to set an internal Google default to singleOrigin right now, as you

say, and the "*iexplore" mapping would continue to work as prior to the

mapping change.  Most if not all project teams would then be able to avoid

test breakages until their schedules allowed them to take a look at which

tests could run in other modes.

-Jen