Closed Bug 937407 Opened 6 years ago Closed 6 years ago

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

Categories

(Toolkit :: XUL Widgets, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla30

People

(Reporter: jgriffin, Assigned: neil)

References

Details

Attachments

(1 file)

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
Arpad, you know how you just paged all this stuff back into your memory? :)
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.
mochitest-browser-chrome TEST_PATH=toolkit/content passes for me on Windows.
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.
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.
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 :(
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
Summary: browser_bug295977_autoscroll_overflow.js fails on OSX/Windows when browser-chrome suite is split into chunks → browser_bug295977_autoscroll_overflow.js, browser_keyevents_during_autoscrolling.js fails on OSX/Windows when browser-chrome suite is split into chunks
(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.
Flags: needinfo?(jgriffin)
Oh, I misunderstood how chunks work.  Guess the only way to reproduce is to let the entire giant third chunk run.
Flags: needinfo?(jgriffin)
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.
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...
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.
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.
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?
(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.
Flags: needinfo?(neil)
this is good news.  possibly Mayasuki could review it.  Maybe :gavin has other thoughts on reviewers.
Flags: needinfo?(gavin.sharp)
Sure, I can review it/find someone to.
Flags: needinfo?(gavin.sharp)
Assignee: nobody → neil
Attached patch Proposed patchSplinter Review
The important bit is ensuring that the popuphidden event listener is not added if we're not actually going to show the popup.
Attachment #8390849 - Flags: review?(gavin.sharp)
awesome, thanks for putting this patch together!
Attachment #8390849 - Flags: review?(gavin.sharp) → review+
https://hg.mozilla.org/mozilla-central/rev/17a33bb88521
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
Thanks for taking care of this :-)
You need to log in before you can comment on or make changes to this bug.