Open Bug 1258895 Opened 4 years ago Updated Last year

Make test_bug426082.html and test_bug656379-1.html work with e10s

Categories

(Core :: DOM: Events, defect, P5)

defect

Tracking

()

Tracking Status
e10s + ---
firefox48 --- affected

People

(Reporter: mccr8, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: btpp-active [fce-active-legacy])

Attachments

(1 file)

These both fail in e10s with "Pressed focused buttons should look different from normal focused buttons." I'm guessing the reason is because the sendMouseEvent() they do to press the button is async.
Blocks: 1218958
Blocks: e10s-tests
tracking-e10s: --- → +
(In reply to Andrew McCreight [:mccr8] from comment #0)
> These both fail in e10s with "Pressed focused buttons should look different
> from normal focused buttons." I'm guessing the reason is because the
> sendMouseEvent() they do to press the button is async.

I was looking into this today and that's the case together with the bizarre way the test listens to paint events to decide when to take a snapshot:

http://hg.mozilla.org/mozilla-central/file/35dddd51e275/dom/events/test/bug426082.html#l51
http://hg.mozilla.org/mozilla-central/file/35dddd51e275/dom/events/test/bug426082.html#l61

Is there a sane way to wait for events in the content process in plain mochitests or should this be converted to a browser mochitest to fix it?
Flags: needinfo?(continuation)
You can see bug 1255173 for an example of having the content process listen for a main process event, by using the SpecialPower proxy, but because this is paint events maybe that's not the right thing to do.

You can see in the function sendWheelAndPaint in EventUtils.js one way to listen for some painting stuff. Maybe kats would have some idea how to deal with painting? I know that works a little differently with APZ.
Flags: needinfo?(continuation) → needinfo?(bugmail.mozilla)
Looking at the test, the code does seem convoluted, but as far as I can tell it should work ok. Line numbers in the discussion below are based on the revision linked to in comment 1.

At line 64, it sends the (async) mouse events, and then line 65 tries to flush the paint. Without e10s the mouse events are sync, so the paint flush happens right away, but with e10s most likely the getBoundingClientRect() call is a no-op in terms of flushing paints. However the test then sets gNeedsPaint to true and spin-loops until it gets sent back to false. The set back to false only happens once a paint actually happens in the area of interest (lines 52-53), which I think is bound to happen eventually. So once it does, the test should take the snapshots correctly and continue.

If the test is falling off the rails I'd be interested to know where. My best guess is that the paint doesn't actually happen because the getBoundingClientRect() happens too early, before the event is processed and nothing else triggers a repaint. If that's the case then I think calling flushApzRepaints on a domwindowutils object right after the getBoundingClientRect() call might do the job of ensuring a paint happens.
Flags: needinfo?(bugmail.mozilla)
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #3)
> If the test is falling off the rails I'd be interested to know where. My
> best guess is that the paint doesn't actually happen because the
> getBoundingClientRect() happens too early, before the event is processed and
> nothing else triggers a repaint. If that's the case then I think calling
> flushApzRepaints on a domwindowutils object right after the
> getBoundingClientRect() call might do the job of ensuring a paint happens.

It's random, depending on the timing it can succeed or any number of tests can fail. I tried it on Linux 64-bits BTW.
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #3)
> If that's the case then I think calling
> flushApzRepaints on a domwindowutils object right after the
> getBoundingClientRect() call might do the job of ensuring a paint happens.

BTW I'll be testing this shortly to see if it fixes the problem.
Calling flushApzRepaints() right after getBoundingClientRect() seems to do the trick. I've run the modified test ~20 times on my machine without being able to reproduce, before I could reproduce 3 times out of 4 runs. I'll prepare a patch and push to try to see if I'm not just being lucky.
Assignee: nobody → gsvelto
Status: NEW → ASSIGNED
Ouch, this doesn't seem to be enough. The test is still failing and the data URI in the log shows a partially drawn image:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=1d2c63a4cd58&selectedJob=19191812&filter-searchStr=Linux%20x64%20opt%20Mochitest%20e10s%20Mochitest%20e10s%20M-e10s%282%29

I had tested only with a debug build and it always succeeded but this is happening with an opt build. I'll re-test it locally and see if I can reproduce.
Whiteboard: btpp-active
Whiteboard: btpp-active → btpp-active [fct-active]
Whiteboard: btpp-active [fct-active] → btpp-active [fce-active]
Unassigning myself since I'm not currently working on this.
Assignee: gsvelto → nobody
Status: ASSIGNED → NEW
Whiteboard: btpp-active [fce-active] → btpp-active [fce-active-legacy]
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.