Closed Bug 948092 Opened 7 years ago Closed 7 years ago

Random failure in test_largemenu.xul

Categories

(Core :: XUL, defect)

x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla29
Tracking Status
firefox27 --- fixed
firefox28 --- fixed
firefox29 --- fixed
b2g-v1.2 --- fixed

People

(Reporter: smaug, Assigned: smaug)

References

(Blocks 1 open bug)

Details

(Whiteboard: [qa-])

Attachments

(1 file, 6 obsolete files)

The test is racy
Attached patch possible patch (obsolete) — Splinter Review
https://tbpl.mozilla.org/?tree=Try&rev=e5e0ef0a0e08

This is evil, but might help.
Attached patch v2 (obsolete) — Splinter Review
Attachment #8344849 - Attachment is obsolete: true
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.
Attachment #8350411 - Flags: review?(roc)
Comment on attachment 8350411 [details] [diff] [review]
hide_menu_sooner.diff

no :(
Attachment #8350411 - Flags: review?(roc)
Attached patch v3 (obsolete) — Splinter Review
https://tbpl.mozilla.org/?tree=Try&rev=6832dd58eb1e
Attachment #8350411 - Attachment is obsolete: true
Attached patch v4 (obsolete) — Splinter Review
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)
Attachment #8350802 - Attachment is obsolete: true
Attachment #8355246 - Attachment is obsolete: true
Attachment #8355283 - Attachment is obsolete: true
Still no luck fixing it. I get the issue locally occasionally even without the patch for bug 930793.
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=opettay@mozilla.com
Attachment #8359755 - Flags: review?(roc)
Comment on attachment 8359755 [details] [diff] [review]
stabilize before running the next test

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

blech
Attachment #8359755 - Flags: review?(roc) → review+
https://hg.mozilla.org/mozilla-central/rev/ec549729ad2e
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla29
Whiteboard: [qa-]
You need to log in before you can comment on or make changes to this bug.