8 Apr
2020
8 Apr
'20
8:59 p.m.
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,
9 Apr
9 Apr
12:52 a.m.
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)
--
David C. Rankin, J.D.,P.E.
---------------------------------------------------------------------
To unsubscribe, e-mail: trinity-users-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail: trinity-users-help(a)lists.pearsoncomputing.net
Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/
Please remember not to top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
4:10 a.m.
On Wed, Apr 8, 2020 at 8:53 PM David C. Rankin <
drankinatty(a)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.
6:25 a.m.
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...
--
David C. Rankin, J.D.,P.E.
---------------------------------------------------------------------
To unsubscribe, e-mail: trinity-users-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail: trinity-users-help(a)lists.pearsoncomputing.net
Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/
Please remember not to top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
2 Jun
2 Jun
8:24 p.m.
New subject: [trinity-users] Re: Problem with twin and recent Firefox repainting when switching desktops
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?
1423
days inactive
1478
days old
4 comments
2 participants
participants (2)
-
David C. Rankin -
Snidely Whiplash