workaround for selenium 2.33 vs firefox 23+

This fixes https://code.google.com/p/google-caja/issues/detail?id=1749

browser tests fail completely on firefox 23+ (beta and aurora)
because selenium's executeScript() fails.

I took a look at why executeScript is failing, and fixing it is
not particularly simple. So instead I'm reducing our dependency
on executeScript, because that's easy, and we really need to
test firefox beta (there's a new failure revealed by this fix).

We use executeScript in two ways:
1. querying firefox for build id, so we can tell different builds
of firefox apart. I've downgraded this to 'best effort'.

2. opening a new window for each browser test. There doesn't really
seem to be much value in doing that, and it complicates the test
driver in weird ways. I've stripped out much of that code, so we
now just re-use the same window instead of opening a new one.

[kpreid2, 2013-07-10 16:39:47]

https://codereview.appspot.com/10963044/diff/1/tests/com/google/caja/plugin/W...
File tests/com/google/caja/plugin/WebDriverHandle.java (right):

https://codereview.appspot.com/10963044/diff/1/tests/com/google/caja/plugin/W...
tests/com/google/caja/plugin/WebDriverHandle.java:116: // we just re-use the
same window.
This will greatly interfere with my workflow, as opening and navigating the
report files is much less convenient than copying URLs out of open browser
windows (or, sometimes, viewing the failure directly in the left-open window).
Furthermore, in the case of third-party-tests, it is often the case that one
wishes to review the pass-count differences among all tests, which information
is not stored in the report; the alternative would be to manually run all tests
or rerun failed tests, which is tediously slow.

Here are two alternate solutions I can think of:

1. Use multiple windows if possible and fall back to a single window if not.

2. Open windows by navigating the browser to a page which opens windows, rather
than using executeScript; a unique name can be provided via parameters in the
URL.

This change would be more acceptable given the following improvements to
reporting:

A. Report more specific failure information from JS tests. Minimal fix would be
to have the qunit-test-driver arrange so the QUnit pass count ends up in the
title (which does get into the report); ideal would be to pass back all of the
jsunit failing tests with their corresponding exceptions.

B. After a test run, output to stdout the URLs (preferably with port set to
8000) of all failed browser tests.

[felix8a, 2013-07-10 16:51:11]

On 2013/07/10 16:39:47, kpreid2 wrote:
>
https://codereview.appspot.com/10963044/diff/1/tests/com/google/caja/plugin/W...
> File tests/com/google/caja/plugin/WebDriverHandle.java (right):
> 
>
https://codereview.appspot.com/10963044/diff/1/tests/com/google/caja/plugin/W...
> tests/com/google/caja/plugin/WebDriverHandle.java:116: // we just re-use the
> same window.
> This will greatly interfere with my workflow, as opening and navigating the
> report files is much less convenient than copying URLs out of open browser

this still leaves failed windows alone. if a test fails, we drop the webdriver
instance so it stays around, and open a new one. is there something else you
need?

[kpreid2, 2013-07-10 17:01:39]

On 2013/07/10 16:51:11, felix8a wrote:
> this still leaves failed windows alone. if a test fails, we drop the webdriver
> instance so it stays around, and open a new one. is there something else
> you need?

Oh, OK.

But doesn't that mean that the new webdriver will open a new browser? I remember
we used to do that, and if someone accidentally breaks _all_ the tests and runs
an unattended runtests, the memory usage of the resulting ~100 copies of Firefox
can make a machine unusable.

[felix8a, 2013-07-10 17:27:56]

On 2013/07/10 17:01:39, kpreid2 wrote:
> On 2013/07/10 16:51:11, felix8a wrote:
> > this still leaves failed windows alone. if a test fails, we drop the
webdriver
> > instance so it stays around, and open a new one. is there something else
> > you need?
> 
> Oh, OK.
> 
> But doesn't that mean that the new webdriver will open a new browser? I
remember
> we used to do that, and if someone accidentally breaks _all_ the tests and
runs
> an unattended runtests, the memory usage of the resulting ~100 copies of
Firefox
> can make a machine unusable.

if that's a problem I can put a max spawn limit there somewhere. I can do that
in a separate CL. our lack of firefox beta testing is hurting more, beta is
going to become release in less than a month.

[kpreid2, 2013-07-10 17:36:04]

On 2013/07/10 17:27:56, felix8a wrote:
> if that's a problem I can put a max spawn limit there somewhere. I can do that
> in a separate CL. our lack of firefox beta testing is hurting more, beta is
> going to become release in less than a month.

Please keep the multi-window operation code, and just drop the WebDriver if
executeScript fails. That will keep the benefits of the current system when
possible, and in the future when WebDriver/Firefox no longer has this bug we
won't have to think about reverting this change.

[felix8a, 2013-07-10 21:38:40]

On 2013/07/10 17:36:04, kpreid2 wrote:
> On 2013/07/10 17:27:56, felix8a wrote:
> > if that's a problem I can put a max spawn limit there somewhere. I can do
that
> > in a separate CL. our lack of firefox beta testing is hurting more, beta is
> > going to become release in less than a month.
> 
> Please keep the multi-window operation code, and just drop the WebDriver if
> executeScript fails. That will keep the benefits of the current system when
> possible, and in the future when WebDriver/Firefox no longer has this bug we
> won't have to think about reverting this change.

That was the first thing I tried, but it didn't work for complicated reasons, I
don't remember why exactly. Looking at the complexity was why I decided it to
get rid of it and do it this way. I can look at it again if you insist, but
that'll be another couple hours of work.

[felix8a, 2013-07-10 21:43:15]

btw, reusing the same window seems to be marginally faster than opening new
windows

[kpreid2, 2013-07-10 21:46:50]

On 2013/07/10 21:38:40, felix8a wrote:
> That was the first thing I tried, but it didn't work for complicated reasons,
I
> don't remember why exactly. Looking at the complexity was why I decided it to
> get rid of it and do it this way. I can look at it again if you insist, but
> that'll be another couple hours of work.

All right. This code LGTM. Add a spawn limit, as previously discussed, in this
CL or later.

[felix8a, 2013-07-10 22:47:26]

@r5479