1252251 - [e10s] Enable test_wheel_default_action.html

Status: RESOLVED FIXED

(Core :: DOM: Events, defect)

Description

[Andrew McCreight [:mccr8]]

I've looked a little at test_wheel_default_action.html. The failure there seemed to happen around a place like this:

    synthesizeKey("0", { accelKey: true });
    ...
    onZoomReset(testZoomedPixelScroll);

onZoomReset adds an observer for "browser-fullZoom:zoomReset", but the observer never fires. It looks like the only place that the observers are notified of that is in browser/base/content/browser-fullZoom.js, but that code doesn't run after the synthesizeKey() call when e10s is enabled.

I thought I saw some bug around about synthesizeKey doesn't actually do anything in the parent process, but maybe that's not right (and I can't find the bug right now).

Comment 1

[Andrew Overholt [:overholt]]

Masayuki, can you take a look, please?

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Sorry, I don't have much time...

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Although, I don't remember the detail of this test, I wonder, why bug 1253041 isn't detected...

> I thought I saw some bug around about synthesizeKey doesn't actually do anything in the parent
> process, but maybe that's not right (and I can't find the bug right now).

synthesizeKey uses nsITextInputProcessor. So, if you want to dispatch a key event from parent process, you can do it with setting "test.events.async.enabled" to true.

Comment 4

[Andrew McCreight [:mccr8]]

(In reply to Masayuki Nakano [:masayuki] (Mozilla Japan) from comment #3)
> Although, I don't remember the detail of this test, I wonder, why bug
> 1253041 isn't detected...

This test currently isn't run on e10s. I think the hang around onZoomReset() was just the first failure I noticed. I hadn't looked into why individual tests were failing yet.

> synthesizeKey uses nsITextInputProcessor. So, if you want to dispatch a key
> event from parent process, you can do it with setting
> "test.events.async.enabled" to true.

Thanks, I'll try looking at that.

Comment 5

[Andrew McCreight [:mccr8]]

I got the full zoom stuff working by setting "test.events.async.enabled" and then hooking up some of the SpecialPowers stuff for observing stuff in the chrome process from the content process.

The next problem is I'm hitting a number of failures in doTestWholeScroll, like this:
2679 INFO TEST-UNEXPECTED-FAIL | dom/events/test/test_wheel_default_action.html | doTestWholeScroll, try whole-scroll to top (line): unexpected scrollTop - got 832, expected +0
2680 INFO TEST-UNEXPECTED-FAIL | dom/events/test/test_wheel_default_action.html | doTestWholeScroll, try whole-scroll to top when scrollTop is already top-most (line): unexpected scrollTop - got 664, expected +0
2681 INFO TEST-UNEXPECTED-FAIL | dom/events/test/test_wheel_default_action.html | doTestWholeScroll, try whole-scroll to bottom (line): unexpected scrollTop - got 1168, expected 2813
2682 INFO TEST-UNEXPECTED-FAIL | dom/events/test/test_wheel_default_action.html | doTestWholeScroll, try whole-scroll to bottom when scrollTop is already bottom-most (line): unexpected scrollTop - got 1336, expected 2813

Maybe it still isn't waiting enough. I'll try investigating more tomorrow.

Comment 6

[Andrew McCreight [:mccr8]]

I've spent some more time trying to look at the behavior of doTestWholeScroll, as described in comment 5. Just looking at the first test, I tried changing the value of mousewheel.default.delta_multiplier_y. If I change it to anything from around 900 to 99999, then scrollTop ends up at 832, which is the same as when e10s is enabled. However, once the multiplier goes to 10000, then suddenly without e10s scrollTop is 0, but it is still 832 with e10s. I'll try to figure out why the sudden switch to 0 without e10s.

Comment 7

[Andrew McCreight [:mccr8]]

Attachment: Enable test_wheel_default_action.html.

I think that bug 1255634 is the last remaining issue with this test, so I'll land this once that is resolved.

Comment 8

[Kartikaya Gupta (email:[e-mail])]

This should be ready to go now, bug 1255634 is in the tree. If you want that patch on 47 as well feel free to go ahead and flag it for uplift.

Comment 9

[Andrew McCreight [:mccr8]]

Thanks for fixing that!

Comment 10

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/3b04ec635018

Comment 11

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/3b04ec635018

Comment 12

[Andrew McCreight [:mccr8]]

This is minor enough that it probably isn't worth uplifting the blocking bug.