Flickering with uBlock Origin & JavaScript disabled
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
People
(Reporter: jannayurevna1979, Unassigned, NeedInfo)
Details
Steps to reproduce:
- Add
www.gov.uk###global-cookie-message
filter or simply addAdGuard/uBO – Cookie Notices
filter list. - Disable JavaScript (
about:config
-javascript.enabled
->false
). - Go to https://www.gov.uk/
- See brief flickering.
Actual results:
A brief flicker occurs when JavaScript is disabled when using uBlock Origin. When JavaScript is enabled, there is no flicker.
https://github.com/uBlockOrigin/uBlock-issues/issues/2875
Expected results:
No flickering.
Comment 1•1 year ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 2•1 year ago
|
||
(In reply to User1 from comment #0)
Steps to reproduce:
- Add
www.gov.uk###global-cookie-message
filter or simply addAdGuard/uBO – Cookie Notices
filter list.- Disable JavaScript (
about:config
-javascript.enabled
->false
).- Go to https://www.gov.uk/
- See brief flickering.
Actual results:
A brief flicker occurs when JavaScript is disabled when using uBlock Origin. When JavaScript is enabled, there is no flicker.
https://github.com/uBlockOrigin/uBlock-issues/issues/2875
Expected results:
No flickering.
Sean, can you help me to confirm if this is expected as https://github.com/uBlockOrigin/uBlock-issues/issues/2875#issuecomment-1764564864 suggests? Also if we think it's a valid issue on Gecko, I am not sure if DOM:Core&HTML is the best component.
Comment 3•1 year ago
|
||
I don't think there's bug, though I am not sure if there's no improvement that can be done.
Here's a profile with JS enabled: https://share.firefox.dev/3Q7sBCO
I think the flicking is caused by the initial blank paint. As far as I can tell, there's was a stylesheet loaded before that paint, and that tick was caused by an user font update. I believe we are working as expected though maybe we can avoid that paint. Maybe user font update doesn't need to schedule a paint if parsing has not done yet?
WDYT Emilio?
Comment 4•1 year ago
|
||
So it seems we're trying to unsuppress painting too soon. I was going to try tweaking the nglayout.initialpaint.delay
prefs etc, but it seems they no longer have such an effect on most pages due to the fast unsuppress that olli added.
Olli, any idea for this? I suspect it's not super-actionable. I suspect this is effectively just bug 1740499, but let me know if that doesn't seem right.
Description
•