948092 - Random failure in test_largemenu.xul

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[Olli Pettay [:smaug]]

The test is racy

Comment 1

[Olli Pettay [:smaug]]

Attachment: possible patch

https://tbpl.mozilla.org/?tree=Try&rev=e5e0ef0a0e08

This is evil, but might help.

Comment 2

[Olli Pettay [:smaug]]

Attachment: v2

Comment 3

[Olli Pettay [:smaug]]

Attachment: hide_menu_sooner.diff

https://tbpl.mozilla.org/?tree=Try&rev=34c2fa4b85de

Comment 4

[Olli Pettay [:smaug]]

Comment on attachment 8350411 [details] [diff] [review]
hide_menu_sooner.diff

Pending still test results and such, but locally this seems to help.
Better to try to close the old menu soon before opening a new one.

Comment 5

[Olli Pettay [:smaug]]

Comment on attachment 8350411 [details] [diff] [review]
hide_menu_sooner.diff

no :(

Comment 6

[Olli Pettay [:smaug]]

Attachment: v3

https://tbpl.mozilla.org/?tree=Try&rev=6832dd58eb1e

Comment 7

[Olli Pettay [:smaug]]

Attachment: v4

https://tbpl.mozilla.org/?tree=Try&rev=58f95c6e29b9

A bit ugly, but let's see what tryserver says about it.
In case of opening a popup the patch delays the update to happen whenever refreshdriver runs the next time or when the OS level widget decides to update everything. This gives more time for the os level widgets to update their state.
(I think there is some odd inconsistency in gtk, or perhaps it is gtk+X issue)

Comment 8

[Olli Pettay [:smaug]]

Attachment: v5

https://tbpl.mozilla.org/?tree=Try&rev=a2eb47c3ece9

Comment 9

[Olli Pettay [:smaug]]

Still no luck fixing it. I get the issue locally occasionally even without the patch for bug 930793.

Comment 10

[Olli Pettay [:smaug]]

Attachment: stabilize before running the next test

This is rather horrible, but popups' event handling is super error prone.
Events dispatched based on when popup is reflowed and many things using
runnables dispatched to thread, yet overflow/underflow use will-paint callback, 
and some events are dispatched synchronously. And linux causing spurious mouse events too
(depending on where pointer is, I assume).
So keeping the ordering of all the events and layout and widget state correct is nightmare,
especially in a test which opens and closes popups without any extra stabilizing time.

The whole thing should be rewritten to be less error prone. Some kind of menu event timeline, which
would force the right order.

I get this bug locally even without the remove-favor-perf-mode, but for some reason this
starts to happen occasionally on try only with removal-of-perf-mode.

https://tbpl.mozilla.org/?tree=Try&rev=cff9971a35cf&pusher=[e-mail]

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 8359755 [details] [diff] [review]
stabilize before running the next test

Review of attachment 8359755 [details] [diff] [review]:
-----------------------------------------------------------------

blech

Comment 12

[Olli Pettay [:smaug]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/ec549729ad2e

Comment 13

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/ec549729ad2e

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/2438db0b749f
https://hg.mozilla.org/releases/mozilla-beta/rev/e0d3bdbe602b
https://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/89514117f0ee