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

Status: NEW

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

Description

[Andrew McCreight [:mccr8]]

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.

Comment 1

[Gabriele Svelto [:gsvelto]]

(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?

Comment 2

[Andrew McCreight [:mccr8]]

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.

Comment 3

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

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.

Comment 4

[Gabriele Svelto [:gsvelto]]

(In reply to Kartikaya Gupta (email:[e-mail]) 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.

Comment 5

[Gabriele Svelto [:gsvelto]]

(In reply to Kartikaya Gupta (email:[e-mail]) 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.

Comment 6

[Gabriele Svelto [:gsvelto]]

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.

Comment 7

[Gabriele Svelto [:gsvelto]]

Attachment: [PATCH] Make tests work in e10s mode by properly flushing paints cross-process

Try run is here: https://treeherder.mozilla.org/#/jobs?repo=try&revision=1d2c63a4cd58

Comment 8

[Gabriele Svelto [:gsvelto]]

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.

Comment 9

[Gabriele Svelto [:gsvelto]]

Unassigning myself since I'm not currently working on this.