Closed
Bug 1149304
Opened 5 years ago
Closed Last year
reftest painting glitches when CSS transform is modified during the test
Categories
(Core :: Graphics, defect)
Core
Graphics
Not set
Tracking
()
RESOLVED
FIXED
mozilla64
Tracking | Status | |
---|---|---|
firefox64 | --- | fixed |
People
(Reporter: jfkthame, Assigned: jfkthame)
Details
(Whiteboard: gfx-noted)
Attachments
(2 files, 1 obsolete file)
2.37 KB,
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
1.16 KB,
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Comment 1•5 years ago
|
||
Updated•5 years ago
|
Whiteboard: gfx-noted
Assignee | ||
Comment 2•5 years ago
|
||
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)
Assignee | ||
Updated•5 years ago
|
Attachment #8585712 -
Attachment is obsolete: true
Assignee | ||
Updated•5 years ago
|
Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
Assignee | ||
Comment 3•5 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=a5c6da85599d
Assignee | ||
Comment 4•5 years ago
|
||
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 | ||
Updated•5 years ago
|
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+
Assignee | ||
Comment 6•5 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/43f8e1806067
Assignee | ||
Comment 7•5 years ago
|
||
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.
Comment 8•5 years ago
|
||
backed this out for unexpected pass on android like https://treeherder.mozilla.org/logviewer.html#?job_id=8342592&repo=mozilla-inbound
Flags: needinfo?(jfkthame)
Assignee | ||
Comment 9•5 years ago
|
||
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)
Comment 11•Last year
|
||
I guess we can close it? Thanks
Status: ASSIGNED → NEW
Flags: needinfo?(jfkthame)
Assignee | ||
Comment 12•Last year
|
||
(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.
Comment 13•Last year
|
||
Pushed by jkew@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/b434eb7d318a Reftest for repaint issues when changing CSS transform. r=roc
Assignee | ||
Comment 14•Last year
|
||
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)
Comment 16•Last year
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/b434eb7d318a
Status: NEW → RESOLVED
Closed: Last year
status-firefox64:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
You need to log in
before you can comment on or make changes to this bug.
Description
•