937407 - browser_bug295977_autoscroll_overflow.js, browser_keyevents_during_autoscrolling.js fails on OSX/Windows when browser-chrome suite is split into chunks

Status: RESOLVED FIXED

(Toolkit :: UI Widgets, defect)

Description

[Jonathan Griffin (:jgriffin)]

When mochitest-browser-chrome is split into chunks (see bug 819963), the test browser_bug295977_autoscroll_overflow.js fails consistently on OSX and Windows with multiple instances of the error:

TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/toolkit/content/tests/browser/browser_bug295977_autoscroll_overflow.js | uncaught exception - TypeError: Property 'handleEvent' is not callable. at chrome://mochikit/content/tests/SimpleTest/specialpowersAPI.js:88

The error does not occur on linux.

full log: https://tbpl.mozilla.org/php/getParsedLog.php?id=30443160&tree=Cedar

Comment 1

[Phil Ringnalda (:philor)]

Arpad, you know how you just paged all this stuff back into your memory? :)

Comment 2

[Arpad Borsos [:Swatinem]]

Tell me :-)

So I see
```
TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/toolkit/content/tests/browser/browser_keyevents_during_autoscrolling.js | uncaught exception - TypeError: Property 'handleEvent' is not callable. at chrome://mochikit/content/tests/SimpleTest/specialpowersAPI.js:88
```
Which i did not write, but I copied the code from there mostly. So maybe its a problem in the harness? Also the type of Error suggests that.

Comment 3

[[e-mail]]

mochitest-browser-chrome TEST_PATH=toolkit/content passes for me on Windows.

Comment 4

[Arpad Borsos [:Swatinem]]

The tests themselves pass:
15:27:56     INFO -  TEST-PASS | chrome://mochitests/content/browser/toolkit/content/tests/browser/browser_bug295977_autoscroll_overflow.js | a should not have scrolled vertically
… and for b-j as well

15:27:57     INFO -  Stack trace:
15:27:57     INFO -      JS frame :: chrome://mochikit/content/tests/SimpleTest/SimpleTest.js :: simpletestOnerror :: line 1159
15:27:57     INFO -      native frame :: <unknown filename> :: <TOP_LEVEL> :: line 0
15:27:57     INFO -  JavaScript error: chrome://mochikit/content/tests/SimpleTest/specialpowersAPI.js, line 88: Property 'handleEvent' is not callable.

Well the stack trace is pretty useless :(

The referenced code is this (specialpowersAPI.js, line 88):
```
function doApply(fun, invocant, args) {
  return Function.prototype.apply.call(fun, invocant, args);
}
```

Which is also not very enlightening :(

I’m pretty much out of options here.

Comment 5

[[e-mail]]

I don't see that error locally, I only see a reference to undefined property x.SpecialPowers_wrappedObject and a bunch of errors relating to character encoding.

Comment 6

[Arpad Borsos [:Swatinem]]

The whole point is that it only occurs when the test is split into chunks (see comment #0). AFAIK thats not the case when running it locally.
Is there a way to run these locally exactly the same way as on the releng machines? In any case, I’m on Linux so I can’t really help to fix this on win/osx :(

Comment 7

[Jonathan Griffin (:jgriffin)]

This problem also affects browser_keyevents_during_autoscrolling.js.

You can run this in chunks locally using:

./mach mochitest-browser --total-chunks 3 --this-chunk 3

Comment 8

[Drew Willcoxon :adw]

(In reply to Jonathan Griffin (:jgriffin) from comment #7)
> ./mach mochitest-browser --total-chunks 3 --this-chunk 3

This doesn't seem to work... it runs more than three tests, and the failing tests aren't among them, but I did stop them after several minutes.

I tried --start-at and --end-at and starting at a varying number of tests before browser_bug295977_autoscroll_overflow.js but couldn't reproduce that way either.

Is there a simple way to replicate the failures locally?  I'm on OS X.

Comment 9

[Drew Willcoxon :adw]

Oh, I misunderstood how chunks work.  Guess the only way to reproduce is to let the entire giant third chunk run.

Comment 10

[[e-mail]]

The test does fail for me when run using the command in comment #7.

Then I realised that I'd forgotten to build debug.

Then I discovered that the other tests generate a boatload of crap.

I just hope I've set my breakpoint at the right place.

Comment 11

[[e-mail]]

Hmm, now that I've built debug, the test isn't failing for me...

And in release mode, I don't have enough information to debug the test...

Comment 12

[[e-mail]]

OK, I've got somewhere now. There is a dead <browser> that is still listening for the autoscroll popup's hiding event. Because the XBL has been unbound there's no handleEvent method left for the event to invoke.

Comment 13

[[e-mail]]

Steps to reproduce problem:
1. Enable autoscroll
2. Middle-click a tab which isn't overflowing
3. Close the tab
4. Middle-click another tab in the same window which is overflowing
5. Cancel the autoscroll
At this point the TypeError will be logged to the console.

The test that exposes the bug is browser_focus_steal_from_chrome_during_mousedown which sends left, middle and right mouse button events to content to ensure that this causes them to become focused. Since the test document does not overflow the autoscroll popup never gets shown but unfortunately the check happens after the popup listener is added. When the browser element is later destroyed it is no longer able to handle the subsequent popuphidden events generated by browser_bug295977_autoscroll_overflow. The test probably passes on Linux because autoscroll is disabled by default so that startScroll never gets invoked on the first test.

Comment 14

[Joel Maher ( :jmaher ) (UTC -8)]

these two tests have been disabled on Cedar and now that we are working on running these tests in chunks and on ec2 on inbound they are failing.  Should we disable them on trunk based trees (inbound) or do we think this can be fixed in the next couple of days?

Comment 15

[[e-mail]]

(In reply to Joel Maher from comment #14)
> these two tests have been disabled on Cedar and now that we are working on
> running these tests in chunks and on ec2 on inbound they are failing. 
> Should we disable them on trunk based trees (inbound) or do we think this
> can be fixed in the next couple of days?

I could write a patch based on comment #13 if you could find someone to review.

Comment 16

[Joel Maher ( :jmaher ) (UTC -8)]

this is good news.  possibly Mayasuki could review it.  Maybe :gavin has other thoughts on reviewers.

Comment 17

[:Gavin Sharp [email: [e-mail]]]

Sure, I can review it/find someone to.

Comment 18

[[e-mail]]

Attachment: Proposed patch

The important bit is ensuring that the popuphidden event listener is not added if we're not actually going to show the popup.

Comment 19

[Joel Maher ( :jmaher ) (UTC -8)]

awesome, thanks for putting this patch together!

Comment 20

[[e-mail]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/17a33bb88521

Comment 21

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/17a33bb88521

Comment 22

[Arpad Borsos [:Swatinem]]

Thanks for taking care of this :-)