Protection panel flickers as the header is expanded
Categories
(Firefox :: Protections UI, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr78 | --- | unaffected |
firefox87 | --- | unaffected |
firefox88 | --- | unaffected |
firefox89 | --- | unaffected |
firefox90 | --- | verified |
People
(Reporter: ehsan.akhgari, Unassigned)
References
(Regression)
Details
(Keywords: regression, Whiteboard: [privacy-panel][skyline])
Attachments
(4 files)
STR:
- Go to www.cnn.com and wait for the page to load.
- Open the protection panel, and click on the (i) icon in the header.
- Watch the panel closely as it gets resized.
The width of the panel changes slightly as the resize is happening, causing a flickering effect. This is very visible if you focus on the right side of the coloured edge of the header as it is expanding.
Updated•5 years ago
|
Comment 1•5 years ago
|
||
Nihanth, can you take a look at this? Is this resolved already?
Updated•5 years ago
|
Reporter | ||
Comment 2•5 years ago
|
||
I can't really reproduce this on Windows any more, though as far as I remember I originally noticed it on Ubuntu...
Comment 3•5 years ago
|
||
I still can reproduce it on Windows 7. It happens mostly only on first expansion.
Reporter | ||
Comment 4•5 years ago
|
||
This is terribly visible in RTL builds, FWIW.
Comment 5•5 years ago
|
||
I was unable to reproduce this. I tried an en-US build with uidirection 1 and -1, and also an arabic build. No flicker in both cases. I did not try on Windows yet.
Comment 6•5 years ago
|
||
(I tried on a Ubuntu 18.04 VM)
Updated•5 years ago
|
Updated•5 years ago
|
Comment 7•4 years ago
|
||
I can reproduce the flickering on Ubuntu 20.10 on any page (attaching a screencast) with both Nightly 89and Firefox 87, it's very slow and jumpy.
The same animation is butter smooth on macOS and flickers a bit on Windows 10 but not as much as on Linux (tested with Nightly on both).
The animation is perfectly smooth on Linux with ESR 78.9 so this is actually a regression.
Comment 8•4 years ago
|
||
Screencast of the flickering I am seeing.
Updated•4 years ago
|
Comment 9•4 years ago
|
||
Looked for a regression and this seems to be introduced somewhere between 2020-05-05 and 2020-05-06.
This is the pushlog that mozregression gave me: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=74d50028caec9d5856a173c98a6172700f1ccc29&tochange=6a43f985307516ec1ae2d413a39cd6d813560b8b
And this is the bug in the pushlog: Bug 1574746
Comment 10•4 years ago
|
||
Thank you Catalin! Sotaro FYI your patch in bug 1574746 caused this regression on Windows/Linux only.
Comment 11•4 years ago
|
||
(In reply to Pascal Chevrel:pascalc from comment #10)
Thank you Catalin! Sotaro FYI your patch in bug 1574746 caused this regression on Windows/Linux only.
On Windows, webrender usage seemed to be triggered by pref gfx.webrender.software.unaccelerated-widget.allow=true(Bug 1704927).
Updated•4 years ago
|
Comment 12•4 years ago
|
||
On Windows, when pref gfx.webrender.debug.force-picture-invalidation=true was set, the symptom became better.
Comment 13•4 years ago
•
|
||
On Windows, when pref layers.force-synchronous-resize=false was set, the problem was mostly addressed for me.
Comment 14•4 years ago
|
||
:mattwoodrow, do you have any ideas why "pref layers.force-synchronous-resize=false" affect to the problem?
Comment 15•4 years ago
|
||
Comment 16•4 years ago
|
||
I don't really know why that pref (forcing a sync IPC message to the compositor) fixes the issue sorry.
I grabbed a screenshot of the frame before, and then during the flicker.
It looks like when we flicker we've re-drawn the content to the larger size (note that the 'Keep your data to yourself' text is now present), but it's been drawn at the wrong position (leaving a gap at the top, and clipping at the bottom).
That seems like a race condition where we've handled part of the resize but not all of it.
Comment 17•4 years ago
•
|
||
I tested on Windows 10 in both Nightly 90 (rounded popup) and in Release 88 (square popup). I also tested in both with gfx.webrender.software.unaccelerated-widget.allow values. Also tested in 88 with webrender disabled.
I definitely see the swiggle popup redraw issue in Nightly. I wasn't able to reproduce any other issue.
We should get the swiggle issue fixed first (tracked by this meta) then see what's left over after that. I get the sense that we might have some jank associated with the expanding panel that's been around for a while, but it's hard to reproduce.
Comment 18•4 years ago
|
||
(In reply to Sotaro Ikeda [:sotaro] from comment #11)
(In reply to Pascal Chevrel:pascalc from comment #10)
Thank you Catalin! Sotaro FYI your patch in bug 1574746 caused this regression on Windows/Linux only.
On Windows, webrender usage seemed to be triggered by pref gfx.webrender.software.unaccelerated-widget.allow=true(Bug 1704927).
I confirmed that the problem happened with pref gfx.webrender.software.unaccelerated-widget.allow=true on 90, 89 and 88 on Win10 PC.
Comment 19•3 years ago
|
||
Is this something that will affect 90 as it rides the trains or are some of the prefs involved nightly only?
[resetting priority/severity since it looks like they were set before this bug morphed into a new thing]
Updated•3 years ago
|
Comment 20•3 years ago
|
||
The problem on Windows was addressed for me with Bug 1709998 fix. I could not reproduce the problem on Linux.
Comment 21•3 years ago
|
||
Catalin, Pascal, are you still seeing this on linux?
Comment 22•3 years ago
|
||
Yep, still happening on Ubuntu 20.04 with Firefox 90.0a1 (2021-05-11)
Comment 23•3 years ago
|
||
Yes I am still seeing the issue (latest nightly, Ubuntu 21.04)
Comment 24•3 years ago
|
||
Pascal Chevrel:pascalc, can you reproduce the problem with pref gfx.webrender.software=true from about:config?
Comment 25•3 years ago
|
||
:csasca, can you reproduce the problem with pref gfx.webrender.software=true from about:config?
Comment 26•3 years ago
|
||
Setting gfx.webrender.software to tue fixes the problem for me
Comment 27•3 years ago
|
||
Same here, setting the pref to true will fix the issue.
Comment 28•3 years ago
|
||
Thank you for the confirmations!
Comment 29•3 years ago
|
||
Weirdly enough, the "i" icon seems to be a no-op for me on Nightly. But the activity in this bug recently seems to indicate it's working fine for y'all? I am going to file a bug but curious if I'm missing something.
Comment 30•3 years ago
|
||
:csasca, is the problem addressed on latest nightly?
Comment 32•3 years ago
|
||
Great!
Updated•3 years ago
|
Updated•3 years ago
|
Comment 33•3 years ago
|
||
(In reply to Nihanth Subramanya [:nhnt11] from comment #29)
Weirdly enough, the "i" icon seems to be a no-op for me on Nightly. But the activity in this bug recently seems to indicate it's working fine for y'all? I am going to file a bug but curious if I'm missing something.
:nhnt11, is a new bug created for it? Thank you.
Comment 34•3 years ago
|
||
(In reply to Sotaro Ikeda [:sotaro] from comment #33)
(In reply to Nihanth Subramanya [:nhnt11] from comment #29)
Weirdly enough, the "i" icon seems to be a no-op for me on Nightly. But the activity in this bug recently seems to indicate it's working fine for y'all? I am going to file a bug but curious if I'm missing something.
:nhnt11, is a new bug created for it? Thank you.
Thank you for flagging me! I forgot to write here - I can't reproduce the issue anymore, so I didn't file a bug. I think this was fixed recently, and beta is working correctly too - it's also possible that I was mistaken about something. :)
Updated•3 years ago
|
Updated•3 years ago
|
Description
•