Closed Bug 1149304 Opened 5 years ago Closed Last year
reftest painting glitches when CSS transform is modified during the test
See the Windows XP failures in https://treeherder.mozilla.org/#/jobs?repo=try&revision=e9dbc6d8dbf1. The ugly black bars visible in the testcase rendering should not exist; they appear to be an artifact of the transform changes. Note that I do not see these artifacts when loading the testcase locally in my WinXP virtual machine. Possibly they are specific to running in the reftest framework; or possibly dependent on graphics hardware/drivers/etc.? Note also that the problem does not occur on Windows 7 reftest jobs, either accelerated or unaccelerated; it seems to be specific to WinXP.
It turns out this test fails (in different ways) on OS X and Android, as well as the WinXP visual glitch. It looks OK when loading and comparing the testcase and reference locally, though; the problem seems to be specific to running in the reftest framework.
Attachment #8586265 - Flags: review?(roc)
Attachment #8585712 - Attachment is obsolete: true
Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
So until we figure out the problem(s) here, we'll need to mark the test as failing on specific platforms.
Attachment #8586266 - Flags: review?(roc)
Assignee: jfkthame → nobody
OS: Windows XP → All
Hardware: x86 → All
Summary: reftest painting glitch on Windows XP when CSS transform is modified → reftest painting glitches when CSS transform is modified during the test
Attachment #8586265 - Flags: review?(roc) → review+
Comment on attachment 8586266 [details] [diff] [review] Mark test as failing on WinXP, OS X and Android Review of attachment 8586266 [details] [diff] [review]: ----------------------------------------------------------------- You should just squash these patches together
Attachment #8586266 - Flags: review?(roc) → review+
Apparently, the patch in bug 1149519 fixes the WinXP failure in this testcase, so I'm removing that part of the fails-if annotation along with that landing.
backed this out for unexpected pass on android like https://treeherder.mozilla.org/logviewer.html#?job_id=8342592&repo=mozilla-inbound
Apparently the failure on android-api-9 is not 100% reliable; we get occasional passes there, resulting in orange test runs. In general, it looks like there's something timing-related about this, as though the reftest capture is happening before the testcase is really ready. (In the OS X failure, it's as though the transform changes haven't happened yet, even though the reftest-wait removal shouldn't happen until afterwards.) :roc, do you see any reason the test should be unreliable in this way?
Flags: needinfo?(jfkthame) → needinfo?(roc)
I don't, unfortunately. The transformed element is probably being layerized, but that should be OK...
I guess we can close it? Thanks
Status: ASSIGNED → NEW
(In reply to Sylvestre Ledru [:sylvestre] from comment #11) > I guess we can close it? Better, we should try re-landing the reftest here, and see whether there are still failures on any current platform. Pushed to try at https://treeherder.mozilla.org/#/jobs?repo=try&revision=8ef0a04228601d3b6763ca61871ae9f9f4e071fc, let's see how that goes.
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/b434eb7d318a Reftest for repaint issues when changing CSS transform. r=roc
Try run looks OK. The issues that were causing failures 4 years ago may well have gotten fixed in the meantime. So provided the reftest sticks and doesn't start producing oranges, we can consider this resolved.
Assignee: nobody → jfkthame
You need to log in before you can comment on or make changes to this bug.