2 Jun
2020
2 Jun
'20
8:24 p.m.
On Wed, Apr 8, 2020 at 4:59 PM Snidely Whiplash <therealgrogan(a)gmail.com wrote:
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.
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?