Closed Bug 1252251 Opened 5 years ago Closed 5 years ago

[e10s] Enable test_wheel_default_action.html

Categories

(Core :: DOM: Events, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla48
Tracking Status
e10s + ---
firefox47 --- wontfix
firefox48 --- fixed

People

(Reporter: mccr8, Assigned: mccr8)

References

(Blocks 1 open bug)

Details

(Whiteboard: btpp-active)

Attachments

(1 file)

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).
Summary: [e10s] Enable → [e10s] Enable test_wheel_default_action.html
Blocks: e10s-tests
tracking-e10s: --- → +
Masayuki, can you take a look, please?
Flags: needinfo?(masayuki)
Whiteboard: btpp-followup-2016-03-08
Sorry, I don't have much time...
Flags: needinfo?(masayuki)
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.
(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.
Depends on: 1253041
Assignee: nobody → continuation
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.
Whiteboard: btpp-followup-2016-03-08 → btpp-active
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.
Depends on: 1255173
Depends on: 1255634
See Also: → 1257932
I think that bug 1255634 is the last remaining issue with this test, so I'll land this once that is resolved.
Attachment #8733391 - Flags: review?(masayuki)
Attachment #8733391 - Flags: review?(masayuki) → review+
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.
Thanks for fixing that!
https://hg.mozilla.org/mozilla-central/rev/3b04ec635018
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
This is minor enough that it probably isn't worth uplifting the blocking bug.
You need to log in before you can comment on or make changes to this bug.