When switching virtual desktops back to the one where Firefox is open, when certain pages are displaying on the active tab, the window contents do not repaint until moving the mouse over a mouseover effect (e.g. a hoverable link) changes the window status. The window then shows its contents.
This started for me with Firefox 73, got somewhat better with Firefox 74 (could only reproduce it on one page, a specific Vbulletin forum listing) and got worse than ever with Firefox 75. Now it happens with most pages that have a list of hoverable links. For example Vbulletin forum listings, and even https://www.kernel.org
This does not happen with Fluxbox, seems to be only with TDE/twin. I can reproduce it on both my Manjaro and Linux From Scratch systems.
I thought maybe enabling the compositing ("composition manager") might help with this (I build support for it, but I don't enable it) but it neither helps nor harms.
A previous cause of this in Firefox was "focusmanager.testmode" but that's set to false now and not applicable.
Anybody else seeing this behaviour, or know of any settings or command line arguments for twin that might change this paint behaviour?
Thanks,
On 04/08/2020 03:59 PM, Snidely Whiplash wrote:
When switching virtual desktops back to the one where Firefox is open, when certain pages are displaying on the active tab, the window contents do not repaint until moving the mouse over a mouseover effect (e.g. a hoverable link) changes the window status. The window then shows its contents.
This started for me with Firefox 73, got somewhat better with Firefox 74 (could only reproduce it on one page, a specific Vbulletin forum listing) and got worse than ever with Firefox 75. Now it happens with most pages that have a list of hoverable links. For example Vbulletin forum listings, and even https://www.kernel.org
This does not happen with Fluxbox, seems to be only with TDE/twin. I can reproduce it on both my Manjaro and Linux From Scratch systems.
I thought maybe enabling the compositing ("composition manager") might help with this (I build support for it, but I don't enable it) but it neither helps nor harms.
A previous cause of this in Firefox was "focusmanager.testmode" but that's set to false now and not applicable.
Anybody else seeing this behaviour, or know of any settings or command line arguments for twin that might change this paint behaviour?
Thanks,
If I recall correctly 73 has hardware acceleration enabled on Linux by default for the first time. This will cause the problem you describe. Check the about:config page and if you have:
layers.acceleration.force-enabled true
You can disable it (which was the default up to that point), and see if the issue remains (may need a restart of firefox for it to take effect, I can't recall)
On Wed, Apr 8, 2020 at 8:53 PM David C. Rankin < drankinatty@suddenlinkmail.com> wrote:
If I recall correctly 73 has hardware acceleration enabled on Linux by default for the first time. This will cause the problem you describe. Check the about:config page and if you have:
layers.acceleration.force-enabled true
Thank you, but yes, absolutely I am using hardware acceleration. I have been using WebRender for a long time, last May, since before they turned it on by default in Firefox 68. While it certainly does not occur without WebRender (I did test that), it is not an acceptable workaround and not a solution. I'm not turning off hardware acceleration in my browser.
This is a recent problem, in the last few months, and does not happen in other window managers.
On 04/08/2020 11:10 PM, Snidely Whiplash wrote:
Thank you, but yes, absolutely I am using hardware acceleration. I have been using WebRender for a long time, last May, since before they turned it on by default in Firefox 68. While it certainly does not occur without WebRender (I did test that), it is not an acceptable workaround and not a solution. I'm not turning off hardware acceleration in my browser.
This is a recent problem, in the last few months, and does not happen in other window managers.
Agreed -- I just shake the mouse...
On Wed, Apr 8, 2020 at 4:59 PM Snidely Whiplash therealgrogan@gmail.com wrote:
When switching virtual desktops back to the one where Firefox is open, when certain pages are displaying on the active tab, the window contents do not repaint until moving the mouse over a mouseover effect (e.g. a hoverable link) changes the window status. The window then shows its contents.
This started for me with Firefox 73, got somewhat better with Firefox 74 (could only reproduce it on one page, a specific Vbulletin forum listing) and got worse than ever with Firefox 75. Now it happens with most pages that have a list of hoverable links. For example Vbulletin forum listings, and even https://www.kernel.org
This does not happen with Fluxbox, seems to be only with TDE/twin. I can reproduce it on both my Manjaro and Linux From Scratch systems.
I thought maybe enabling the compositing ("composition manager") might help with this (I build support for it, but I don't enable it) but it neither helps nor harms.
A previous cause of this in Firefox was "focusmanager.testmode" but that's set to false now and not applicable.
Anybody else seeing this behaviour, or know of any settings or command line arguments for twin that might change this paint behaviour?
I'm including the whole post for context here. My main objective was to see if it was happening to anyone else, or just me. I got a satisfactory answer from David C. Rankin that indicated it wasn't just me.
I'm happy to report that this problem is fixed again in Firefox 77.0
Also, it wasn't only Trinity/twin but I also discovered it was happening IF compositing in XFCE (mild compositing effects, transparency and stuff) was turned off. I didn't have XFCE installed at the time. It was not occurring in Fluxbox. So I would revise that to saying it was happening in SOME non-compositing window managers. It's moot now because it was obviously just a Firefox problem, not any problem with the window manager itself and it's fixed now.
-
David C. Rankin -
Snidely Whiplash