Closed Bug 1149304 Opened 5 years ago Closed Last year

reftest painting glitches when CSS transform is modified during the test


(Core :: Graphics, defect)

Not set



Tracking Status
firefox64 --- fixed


(Reporter: jfkthame, Assigned: jfkthame)


(Whiteboard: gfx-noted)


(2 files, 1 obsolete file)

See the Windows XP failures in 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.
Whiteboard: gfx-noted
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
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
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
Flags: needinfo?(jfkthame)
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...
Flags: needinfo?(roc)
I guess we can close it?
Flags: needinfo?(jfkthame)
(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, let's see how that goes.
Pushed by
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.
Flags: needinfo?(jfkthame)
Assignee: nobody → jfkthame
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
You need to log in before you can comment on or make changes to this bug.