Closed Bug 1512754 Opened 5 years ago Closed 5 years ago

Non-webrender regression in Nightly (for vuetify library)

Categories

(Core :: Layout, defect, P3)

65 Branch
Unspecified
All
defect

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
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
[Tracking Requested - why for this release]: Very visible recent regression that we probably don't want to ship.
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.
Attached file A reduced test case
A problem here seems that opacity value is not factored into the background-color animation.
Assignee: nobody → hikezoe
Status: NEW → ASSIGNED
Flags: needinfo?(hikezoe)
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
(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
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
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.
https://hg.mozilla.org/mozilla-central/rev/0132b59bb093
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla66
Depends on: 1513243
Please nominate this for Beta approval when you get a chance.
Flags: needinfo?(hikezoe)
Flags: in-testsuite+
The feature of the background-color animations on the compositor is pref-ed off on beta.
Flags: needinfo?(hikezoe)
See Also: → 1516948
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: