Closed
Bug 1339317
Opened 7 years ago
Closed 5 years ago
Intermittent browser/base/content/test/general/browser_windowopen_reflows.js | This test contains no passes, no fails and no todos. Maybe it threw a silent exception? Make sure you use waitForExplicitFinish() if you need it. -
Categories
(Firefox :: General, defect)
Firefox
General
Tracking
()
RESOLVED
WORKSFORME
Firefox 54
Tracking | Status | |
---|---|---|
firefox54 | --- | fixed |
People
(Reporter: intermittent-bug-filer, Unassigned)
References
Details
(Keywords: intermittent-failure, Whiteboard: [stockwell disabled])
Attachments
(2 files)
Filed by: philringnalda [at] gmail.com https://treeherder.mozilla.org/logviewer.html#?job_id=76871479&repo=mozilla-central https://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-central-macosx64-debug/1486998400/mozilla-central_yosemite_r7-debug_test-mochitest-e10s-browser-chrome-2-bm135-tests1-macosx-build45.txt.gz
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment 3•7 years ago
|
||
I am not sure if this high rate of failures is due to retriggers, but I am seeing this specific failure often on osx only, a mix between e10s/non-e10s opt and debug. This is the commit range on mozilla-central where it looks to have started: https://hg.mozilla.org/mozilla-central/pushloghtml?changeset=383dce08a941 Just looking at commit messages, I would suspect bug 1338439 is the root cause. Looking in the logs, there is no output from this test case, the screenshot looks like a blank tab as well (which seems to be common in test case screenshots these days). Here is the link to the source code: https://dxr.mozilla.org/mozilla-central/source/browser/base/content/test/general/browser_windowopen_reflows.js?q=path%3Abrowser_windowopen_reflows.js&redirect_type=single We add a weakReflowObserver and this has the opportunity to complete if the path="" (native code triggered it). If it seems completely impossible that this test failure is caused by any of these patches, do speak up.
Flags: needinfo?(markh)
Comment 4•7 years ago
|
||
yeah tried to nail this down, seems something in the merge from https://hg.mozilla.org/mozilla-central/rev/1060668405a9399774c205430de4a7001d3f27ac bite with something different :(
Comment 5•7 years ago
|
||
(In reply to Joel Maher ( :jmaher) from comment #3) > This is the commit range on mozilla-central where it looks > to have started: > https://hg.mozilla.org/mozilla-central/pushloghtml?changeset=383dce08a941 > > Just looking at commit messages, I would suspect bug 1338439 is the root > cause. I think it's extremely unlikely to be bug 1338439 - the code touched by that bug almost certainly isn't executed by any mochitests. I agree nothing else in that commit range looks obvious either.
Flags: needinfo?(markh)
Comment hidden (Intermittent Failures Robot) |
Comment 7•7 years ago
|
||
Mike Conley and Matt Noorenberghe would be my first bets for people who might be able to help here. We can shut up the failure message by making the test do an ok(true) if we get a paint without any reflows (which in principle isn't a bad thing) but given there's no clear/reproducible cause for not getting reflows anymore, this feels more like we're no longer testing the right thing, which *is* bad. Mike, maybe the way we're waiting for paints here is to blame, do you know?
Flags: needinfo?(mconley)
Comment hidden (mozreview-request) |
Comment 9•7 years ago
|
||
My current best theory is that the painting / gfx changes in that merge increased the likelihood of compositor races. Not even sure how a compositor race could occur here (how could a window have fired MozAfterPaint early?), but I'll at least discount the possibility. Try push at https://treeherder.mozilla.org/#/jobs?repo=try&revision=7d219df03d03 I'll keep the needinfo open until some results come in for us to look at.
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Updated•7 years ago
|
Attachment #8838654 -
Flags: review?(gijskruitbosch+bugs)
Comment 12•7 years ago
|
||
Try build looks pretty good: https://treeherder.mozilla.org/#/jobs?repo=try&revision=7d219df03d03a493a7088eb5db26d65d0d034314
Flags: needinfo?(mconley)
Comment hidden (Intermittent Failures Robot) |
Comment 14•7 years ago
|
||
mozreview-review |
Comment on attachment 8838654 [details] Bug 1339317 - Make browser_windowopen_reflows.js more resilient to compositor races. https://reviewboard.mozilla.org/r/113486/#review115384 This patch makes intuitive sense on the assumption that the current behaviour from platform isn't considered a bug, but should we audit our code for other cases where we use mozafterpaint? For instance, I seem to recall reader mode uses mozafterpaint as well... perhaps we need a more robust API that frontend can use when it depends on stuff like this? :-(
Attachment #8838654 -
Flags: review?(gijskruitbosch+bugs) → review+
Comment hidden (Intermittent Failures Robot) |
Comment 16•7 years ago
|
||
Pushed by mconley@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/5b31af0f059b Make browser_windowopen_reflows.js more resilient to compositor races. r=Gijs
Comment 17•7 years ago
|
||
mozreview-review-reply |
Comment on attachment 8838654 [details] Bug 1339317 - Make browser_windowopen_reflows.js more resilient to compositor races. https://reviewboard.mozilla.org/r/113486/#review115384 Good call. I've filed bug 1341294 to try to make this better. Thanks, Gijs.
Comment hidden (Intermittent Failures Robot) |
Comment 19•7 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/5b31af0f059b
Status: NEW → RESOLVED
Closed: 7 years ago
status-firefox54:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 54
Comment 20•7 years ago
|
||
That Try run did indeed look very very good. Unfortunately, I've already starred a good sized armload of failures on pushes after you landed.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 21•7 years ago
|
||
The remaining orange seems to be only entirely OSX-specific. Maybe that's a clue?
Comment 22•7 years ago
|
||
(In reply to :Gijs from comment #21) > The remaining orange seems to be only entirely OSX-specific. Maybe that's a > clue? Hm. Looking at the previous OrangeFactor Robot comments, it looks like OS X was always the most common platform for this orange, with rare exception. I have a feeling we haven't changed anything here. Shoot. :/
Comment hidden (Intermittent Failures Robot) |
Comment 24•7 years ago
|
||
given the high failure rates here, I am going to get a patch queued up for disabling this on osx- if there are other ideas, I am happy to help out on those efforts.
Comment 25•7 years ago
|
||
getting my ducks lined up, happy to wait a day before pushing.
Attachment #8840535 -
Flags: review?(mconley)
Comment hidden (Intermittent Failures Robot) |
Comment 27•7 years ago
|
||
Comment on attachment 8840535 [details] [diff] [review] disable test on osx to reduce the pain Review of attachment 8840535 [details] [diff] [review]: ----------------------------------------------------------------- I'm okay with this, so long as you file a follow-up bug to get this thing properly investigated and re-enabled. :)
Attachment #8840535 -
Flags: review?(mconley) → review+
Comment 28•7 years ago
|
||
my plan is to keep this bug so we have history, etc. I am happy to file a different bug and pester people to get this started.
Keywords: leave-open
Comment 29•7 years ago
|
||
Pushed by jmaher@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/473d5e1d8e07 Intermittent browser/base/content/test/general/browser_windowopen_reflows.js. r=mconley
Comment 30•7 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/473d5e1d8e07
Comment hidden (Intermittent Failures Robot) |
Updated•7 years ago
|
Whiteboard: [stockwell disabled]
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment 34•5 years ago
|
||
This test no longer exists in mozilla-central
Status: REOPENED → RESOLVED
Closed: 7 years ago → 5 years ago
Resolution: --- → WORKSFORME
Updated•5 years ago
|
Keywords: leave-open
You need to log in
before you can comment on or make changes to this bug.
Description
•