Closed Bug 1339317 Opened 3 years ago Closed 8 months ago
_windowopen _reflows .js | This test contains no passes, no fails and no todos . Maybe it threw a silent exception? Make sure you use wait For Explicit Finish() if you need it . -
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
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.
yeah tried to nail this down, seems something in the merge from https://hg.mozilla.org/mozilla-central/rev/1060668405a9399774c205430de4a7001d3f27ac bite with something different :(
(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.
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?
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.
Attachment #8838654 - Flags: review?(gijskruitbosch+bugs)
Try build looks pretty good: https://treeherder.mozilla.org/#/jobs?repo=try&revision=7d219df03d03a493a7088eb5db26d65d0d034314
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+
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/5b31af0f059b Make browser_windowopen_reflows.js more resilient to compositor races. r=Gijs
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.
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 → ---
The remaining orange seems to be only entirely OSX-specific. Maybe that's a clue?
(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. :/
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.
getting my ducks lined up, happy to wait a day before pushing.
Attachment #8840535 - Flags: review?(mconley)
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+
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.
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/473d5e1d8e07 Intermittent browser/base/content/test/general/browser_windowopen_reflows.js. r=mconley
Whiteboard: [stockwell disabled]
Status: REOPENED → RESOLVED
Closed: 3 years ago → 8 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.