Closed Bug 1317149 Opened 8 years ago Closed 8 years ago

Intermittent grid-fragmentation-dyn1-002.html == grid-fragmentation-002-ref.html | image comparison, max difference: 255, number of differing pixels: 9533

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla55
Tracking Flags:
Tracking Status
firefox52 --- unaffected
firefox-esr52 --- unaffected
firefox53 --- fixed
firefox54 --- fixed
firefox55 --- fixed

People

(Reporter: aryx, Assigned: MatsPalmgren_bugz)

References

Details

(Keywords: intermittent-failure, Whiteboard: [stockwell disabled])

Attachments

(2 files, 1 obsolete file)

Somewhat simplified testcase
832 bytes, text/html
Details
comment out the bit that fails
2.54 KB, patch
Details | Diff | Splinter Review
See Also: → 1316257
See Also: → 1341295, 1341118, 1264056, 1339798
There are several languishing bugs for intermittent failures in layout/reftests/css-grid/grid-fragmentation... tests. :jet - Can you find someone to have a look, in hopes of making these tests more reliable?
Flags: needinfo?(bugs)
and the culprit is bug 1343078: https://treeherder.mozilla.org/#/jobs?repo=autoland&filter-searchStr=android%20debug%20reftest-26&tochange=9e21c2dc1b0da1c450462a3f5458d6c6d547fd3a&fromchange=1ecb6fcbdb2ad7cff1d4c3749973947d4c113282&selectedJob=83857429 the failure rate posted here is deceptive as we run once every 5 pushes, so that leaves us with a much higher failure rate at least on autoland and inbound. :bz, I see you are the patch author here, can you take a look at this bug?
Blocks: 1343078
Flags: needinfo?(bzbarsky)
Whiteboard: [stockwell needswork]
So... The link in comment 10 shows this happening on aurora at least once. Bug 1343078 is not on aurora. Looking at the actual test failure, the third test from the end has the green bit in the second and third column in the test, whereas the reference has it all it to be in the first column. See <https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml#logurl=https://queue.taskcluster.net/v1/task/Y_QkuZ7ESSaIKab0c1C-oA/runs/0/artifacts/public/logs/live_backing.log&only_show_unexpected=1> for example. If I load layout/reftests/css-grid/grid-fragmentation-dyn1-002.html or layout/reftests/css-grid/grid-fragmentation-002.html or layout/reftests/css-grid/grid-fragmentation-002-ref.html directly in the browser, in a March 15 nightly, they all render with the green bit in the second and third column. So the "weird" rendering here is the _reference_, not the test, iirc. If I load those files with a March 1 build, way before bug 1343078 landed, I get the same behavior: they all match the test, as shown in the reftest analyzer logs, but not the reference... Mats, what is the expected rendering of that third-from-the-end test?
Flags: needinfo?(mats)
OK, in both current tip and a March 1 nightly I can cause layout/reftests/css-grid/grid-fragmentation-002.html or layout/reftests/css-grid/grid-fragmentation-002-ref.html to have the "all the green in the first column" rendering on that third from last test by inserting <script>document.body.offsetWidth;</script> somewhere after that test. If I put that flush _before_ the third-from-last test, I get the "green in columns 2 and 3" rendering. If I put it anywhere after that test. I get the "first column only" rendering. This is rather bizarre. On the other hand, evaluating document.body.offsetWidth _after_ the page is done loading does not seem to change the rendering....
This is based on layout/reftests/css-grid/grid-fragmentation-002-ref.html but with various stuff ripped out. The layout depends on whether the layout flush happens...
Flags: needinfo?(bzbarsky)
The expected rendering is the one shown for the -ref in this case. Fwiw, I think our support for fragmentating abs.pos. is somewhat flaky in general (not just in Grid), especially with dynamic DOM changes like in this test, so I don't think this is a bug in the Grid layout code per se. Bug 1264056 is also tracking failures in the same underlying test (grid-fragmentation-002.html). grid-fragmentation-dyn1-002.html etc is just loading that test, doing a few DOM mutations that results in the same DOM tree so it should have the same rendering afterwards. http://searchfox.org/mozilla-central/source/layout/reftests/css-grid/grid-fragmentation-dyn1-002.html The failures in bug 1264056 looks exactly the same, so perhaps we should just comment out that part of the test for now (the 3rd grid from the end) and deal with it in a follow-up bug?
Flags: needinfo?(mats)
Attached patch comment out the bit that fails (obsolete) — — Splinter Review
Assignee: nobody → mats
> The expected rendering is the one shown for the -ref in this case. Well, we only get that rendering if we happen to flush at just the right time. :( > The failures in bug 1264056 looks exactly the same Indeed. I'm still a little confused by comment 10, given that the failures in this bug way predate bug 1343078. ;)
No longer blocks: 1343078
Flags: needinfo?(bugs)
I filed bug 1347692 about it. It also occurs with display:block instead of grid, fwiw.
Attachment #8847756 - Attachment is obsolete: true
Pushed by ryanvm@gmail.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/d27b3d263111 Comment out a part of this test that causes to many intermittent failures. r=me
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/d27b3d263111
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox55: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
Blocks: 1264056
Whiteboard: [stockwell needswork] → [stockwell disabled]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: