birchill / 10ten-ja-reader

A browser extension to translate Japanese by hovering over words.
https://addons.mozilla.org/firefox/addon/10ten-ja-reader/
GNU General Public License v3.0
596 stars 45 forks source link

Browser background overriden #1354

Open No3371 opened 12 months ago

No3371 commented 12 months ago

For context, some Firefox users do customization like this to stop white flash every time a page is being loaded, because our nocturnal eyes can't take the brightness and it hurts.

My customization hasn't been working properly for some sites and I decided to investigate. After some toggling I figured out it's caused by 10ten.

I don't expect this to be "fixed" on your end, but I hope maybe we can figure out what element is that white flash so I can add it to the css to override its background color.

https://github.com/birchill/10ten-ja-reader/assets/1814971/82031f28-35df-4904-82e0-2d8ea41b6a7a

birtles commented 12 months ago

Hi! Thank you for filing this. Sorry for the trouble 10ten is causing you here. I'm afraid the link didn't work for me. I get Non-Image content-type returned. I'd certainly love to investigate this and find out what the problem is.

No3371 commented 12 months ago

Apologies, I accidentally used image markdown syntax.

No3371 commented 12 months ago

Just to clarify, It's not 10ten being buggy or something, other extensions can make this happens too, because we all need to put the elements into the html so things show up. It's just that sometimes the elements are not covered by the customization css.

For example, this css is not covering something from 10ten on some sites and results in the white flash:

#main-window,
#browser vbox#appcontent tabbrowser,
#content,
#tabbrowser-tabpanels,
tabbrowser tabpanels,
browser,
browser[type=content-primary],
browser[type=content] > html {
  background: #111111 !important;
}
No3371 commented 12 months ago

For example, with 10ten enabled, the white flash happens when opening https://www.woltlab.com/en/ from other sites or new tab.

birtles commented 12 months ago

Hmm, I'm not sure. I'll need to look into it a bit more tomorrow. I don't think 10ten should be adding anything to the page until you hover over something (it used to add this tenten-safe-area-provider element but I'm pretty sure that's fixed).

There was another bug a long time ago where 10ten was causing flicker on page load for some pages but I'm pretty sure that was fixed too.

I don't suppose you have the puck enabled? (Unlikely).

Another possibility is that when the 10ten script is injected it is affecting the first paint timing such that the page gets painted before the user stylesheet is applied. It seems unlikely (if that were the case, I'd expect other web pages to have the same problem, and I'd expect userChrome.css to be applied from the start) but I recall that Firefox has heuristics to delay the first paint in order to avoid flicker so I guess it's possible.

No3371 commented 12 months ago

Actually, I do have the puck enabled! I just didn't bother to disable it 🤣 And the white flash really just stop showing up if I disable it.

And on the website showing white flashes, there IS a <div id="tenten-safe-area-provider" style="all: initial;"></div>!

It seems like we are getting close to an answer very quick, no?

birtles commented 12 months ago

I dug into this a bit and here's what I found out so far. Looking at https://www.woltlab.com/en/, it uses JS to set data-color-scheme on the root element which causes the stylesheet to select the dark colors.

However, that JS runs as part of a render-blocking script:

const colorScheme = matchMedia("(prefers-color-scheme: dark)").matches ? "dark" : "light";
document.documentElement.dataset.colorScheme = colorScheme;

Furthermore, the styles are in a render-blocking stylesheet.

So all of that should happen before the first paint.

So even if injecting the puck and safe area provider triggers a sync layout flush, nothing should be painted until the script and stylesheet that set up the dark mode have been run/applied.

However, it looks like content scripts behave differently.

If I set a breakpoint on the code that sets up the dark mode attribute I can see that the puck has already been injected even before the page is first rendered:

image

So it looks like content scripts are able to run before the scripts in web pages and trigger a paint too.

If that's the case, I guess we could try to have 10ten delay injecting its puck and safe-area-provider until the document reaches the interactive state. Or alternatively it might be possible to just spin the event loop once.

No3371 commented 11 months ago

I don't have enough front end knowledge to have a opinion, so let's just try that 😄