Closed
Bug 1512754
Opened 5 years ago
Closed 5 years ago
Non-webrender regression in Nightly (for vuetify library)
Categories
(Core :: Layout, defect, P3)
Tracking
()
RESOLVED
FIXED
mozilla66
Tracking | Status | |
---|---|---|
firefox-esr60 | --- | unaffected |
firefox64 | --- | unaffected |
firefox65 | --- | disabled |
firefox66 | --- | fixed |
People
(Reporter: stevencherry, Assigned: hiro)
References
()
Details
(Keywords: regression)
Attachments
(2 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0 Steps to reproduce: On Nightly, 12/7/2018 1.In about.config, set gfx.webrender.all = false and restart. 2. Navigate to https://vuetifyjs.com/en/components/buttons 3. Hover over one of the buttons on page. Actual results: The button highlight flashes white then returns to base color Expected results: The highlight state should be subtle and not flash back to base. When gfx.webrender.all = true, this bug does not happen. Chrome also displays correct behavior of vuetify buttons
Comment 1•5 years ago
|
||
mozregression --good 2018-11-07 --bad 2018-12-07 -a https://vuetifyjs.com/en/components/buttons > 8:39.19 INFO: Last good revision: 2d8ce84e0107c99974201c1b67864786b22f3ff8 > 8:39.19 INFO: First bad revision: 94ecc40729d0302ee3953dbab0d280d4a6b174c4 > 8:39.19 INFO: Pushlog: > https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=2d8ce84e0107c99974201c1b67864786b22f3ff8&tochange=94ecc40729d0302ee3953dbab0d280d4a6b174c4 > > 94ecc40729d0 Hiroyuki Ikezoe — Bug 1504065 - Drop text in the child element inside background-color animated element to avoid fuzziness on Windows 7 GPU. r=birtles > a30f77050399 Hiroyuki Ikezoe — Bug 1504065 - Support background-color animations on the compositor for nsIDOMWindowUtils::GetOMTAValue. r=birtles > d99d8f275d8b Hiroyuki Ikezoe — Bug 1504065 - Run background-color animations on the compositor. r=birtles
Blocks: 1504065
Status: UNCONFIRMED → NEW
Has Regression Range: --- → yes
Has STR: --- → yes
Component: Untriaged → Layout
Ever confirmed: true
Flags: needinfo?(hikezoe)
Keywords: regression
OS: Unspecified → All
Product: Firefox → Core
Same issue here on Firefox Nightly on linux. Examples: https://gfycat.com/AptHeftyKoalabear https://gfycat.com/NegligibleUnfinishedHog This does not happen in other browsers
Comment 3•5 years ago
|
||
[Tracking Requested - why for this release]: Very visible recent regression that we probably don't want to ship.
Assignee | ||
Comment 4•5 years ago
|
||
Background-color animations on the compositor will not be shipped in Firefox 65 since it's enabled only on nightly at this moment, it will be enabled on release channels once it's supported on WebRender (bug 1510030). Anyway, at first glance we maybe mis-use frames for pseudo elements for color layers? I will investigate it today.
tracking-firefox65:
? → ---
Assignee | ||
Comment 5•5 years ago
|
||
A problem here seems that opacity value is not factored into the background-color animation.
Assignee: nobody → hikezoe
Status: NEW → ASSIGNED
Flags: needinfo?(hikezoe)
Assignee | ||
Comment 6•5 years ago
|
||
But the situations that the issue happens seems to be very limited, if there is some text inside the element in attachment 9030184 [details], the problem doesn't happen.
Priority: -- → P3
Assignee | ||
Comment 7•5 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=5a6fb9ceb8c4de638d40d0b8d8037c6fe2fa0573
Assignee | ||
Comment 8•5 years ago
|
||
(In reply to Hiroyuki Ikezoe (:hiro) from comment #7) > https://treeherder.mozilla.org/#/ > jobs?repo=try&revision=5a6fb9ceb8c4de638d40d0b8d8037c6fe2fa0573 In this try, I did use 0.1 for the opacity value in a reftest I added, but unfortunately it resulted the reftest failure [1]. The difference between the test and the reference is 1 value on each RGB component on every pixel. I think, when the background-color is static, the opacity value is factored into in alpha component in the background-color (the result is stored nscolor at this moment) and then we composite with the body background (white) on the compositor, and when the background-color is animated on the compositor, we composite the opacity, the background-color animation and the body background color at the same time. So I think this difference causes the 1 value difference. I should also mention that the composite process here depends on layer backend, actually I don't see any difference on my local linux box at all. Anyway, using 0.5 for the opacity seems to work on try servers. https://treeherder.mozilla.org/#/jobs?repo=try&revision=8eb760a7075004f31618a988c24afa49526f2255 [1] https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml#logurl=https://queue.taskcluster.net/v1/task/HtGzhArEQGSCmb8-PECdIQ/runs/0/artifacts/public/logs/live_backing.log&only_show_unexpected=1
Assignee | ||
Comment 9•5 years ago
|
||
We need to do the same thing what we did for opacity display items in bug 1395151.
Comment 10•5 years ago
|
||
Pushed by hikezoe@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/0132b59bb093 Don't apply opacity to background color display items if the background-color is going to be animated on the compositor. r=birtles
Assignee | ||
Comment 11•5 years ago
|
||
I had to add fuzzy-if on MacOSX and on (Windows 7 for not using GPUProcess and layersGPUAccelerated) because the 1-value differences happened on those platforms. I filed bug 1513155 for investigating it.
Comment 12•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/0132b59bb093
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
status-firefox66:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla66
Comment 13•5 years ago
|
||
Please nominate this for Beta approval when you get a chance.
Assignee | ||
Comment 14•5 years ago
|
||
The feature of the background-color animations on the compositor is pref-ed off on beta.
Flags: needinfo?(hikezoe)
Updated•5 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•