STR:

1. Go to www.cnn.com and wait for the page to load.
2. Open the protection panel, and click on the (i) icon in the header.
3. 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.

Nihanth, can you take a look at this? Is this resolved already?

I can't really reproduce this on Windows any more, though as far as I remember I originally noticed it on Ubuntu...

I still can reproduce it on Windows 7. It happens mostly only on first expansion.

This is terribly visible in RTL builds, FWIW.

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.

(I tried on a Ubuntu 18.04 VM)

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.

Screencast of the flickering I am seeing.

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

Thank you Catalin! Sotaro FYI your patch in bug 1574746 caused this regression on Windows/Linux only.

(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).

On Windows, when pref gfx.webrender.debug.force-picture-invalidation=true was set, the symptom became better.

On Windows, when pref layers.force-synchronous-resize=false was set, the problem was mostly addressed for me.

:mattwoodrow, do you have any ideas why "pref layers.force-synchronous-resize=false" affect to the problem?

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.

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.

(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.

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]

The problem on Windows was addressed for me with Bug 1709998 fix. I could not reproduce the problem on Linux.

Catalin, Pascal, are you still seeing this on linux?

Yep, still happening on Ubuntu 20.04 with Firefox 90.0a1 (2021-05-11)

Yes I am still seeing the issue (latest nightly, Ubuntu 21.04)

Pascal Chevrel:pascalc, can you reproduce the problem with pref gfx.webrender.software=true from about:config?

:csasca, can you reproduce the problem with pref gfx.webrender.software=true from about:config?

Setting gfx.webrender.software to tue fixes the problem for me

Same here, setting the pref to true will fix the issue.

Thank you for the confirmations!

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.

:csasca, is the problem addressed on latest nightly?

Yes, it is fixed on 90.0a1 (2021-05-17)

Great!

(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.

(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. :)