Some sites show as completely white after a fraction of second (Firefox 102)

[MrKrzYch00]

In Firefox v102.0b3 some sites flash with content and go completely blank (white) when this plugin is enabled (github repository view, microsoft, bugzilla). After turning the plugin off the site shows normally (tried with all plugins disabled, just toggling this one).
Console records: "Content Security Policy: The page’s settings blocked the loading of a resource at inline (“script-src”)."

A list of blacklisted domains may be sufficient if this problem can't be fixed.

[jaatroko]

I just tried https://github.com/jaatroko/link-status-redux, https://www.microsoft.com/fi-fi/ and https://www.bugzilla.org/ with Firefox 102.0b3 (Linux 64-bit) and they all work normal for me. Did you try with a clean profile with only LSR installed?

[MrKrzYch00]

Just now, and this is very strange indeed. Have both processes with -no-remote open and in fresh one everything does indeed work correctly but not with my old one, both having only this plugin enabled. Hmmm...
I wonder what it really is that causes this strange behavior... may need to keep verifying setting by setting (in about:config) to see if I pin-point what interferes with your plugin's correct work.

[jaatroko]

Let me know if you find the cause.

[MrKrzYch00]

Got it, occurs with the dark firefox theme.
How to reproduce:

1. Create fresh profile,
2. Open some github repository
3. Download Link Status Redux
4. Go to Add-ons and themes
5. Enable Dark theme

[jaatroko]

After some digging I found the cause and pushed a workaround, see commit b4f3cdf for details. This seems to be a Firefox bug. Seeing as you are using Firefox Beta, I think you are more prepared to file a Firefox bug than I, so I will leave it to you.

Before I publish a new version at AMO I will check if there is some code cleanup I could do, so it will take from a few days to a week. In the meantime you can load the Github master as a temporary addon for testing.

[MrKrzYch00]

Firefox bug report filed: https://bugzilla.mozilla.org/show_bug.cgi?id=1772740

[jaatroko]

Version 3.15 now available from AMO.

[101Monkey]

Don't know it that will help, but I've also encountered a "white problem". I initially thought that it was a conflict between "Link Status Redux" and "SingleFile" (another extension). There's a thread about it here:

gildas-lormeau/SingleFile#993

The problem started today, after both SingleFile and Firefox were updated (I've been using both SingleFile and Link Status Redux for a while, and never had a problem with either). Reverting to a previous version of SingleFile didn't fix the problem. So Firefox becomes the main suspect (since Link Status Redux wasn't updated today). But SingleFile's author also mentioned, in the same thread, that there's a "Link Status Redux" tag that might be involved in the problem. A problem that was latent before today's Firefox update.

[jaatroko]

As switching to a light theme fixes the problem with SingleFile, this is indeed the same Firefox bug but the CSS workaround does not work with SingleFile. I have not looked at the code, but my guess is that SingleFile does something (possibly modifying the color-scheme property?) to the page HTML/CSS which breaks the workaround.

I'll reopen and leave this issue open until the Firefox bug is properly resolved, so it will be more easily found by people encountering similar problems.

[gildas-lormeau]

Hi @jaatroko, author of SingleFile here.

I tried to understand what could cause this issue on my end. For example, I tried to remove all the CSS injected by SingleFile in the editor and its iframe. I also removed <meta name="color-scheme" content="light dark"> from editor.html. That did not change anything. Note that, strangely, if I remove all the styles from the <div> injected by your extension with the debugger, the problem remains, even it has a size of 0x0px.

[gildas-lormeau]

My bad, I did not see there was a shadow root content... The issue can be circumvented by removing color-scheme: light dark !important; on the iframe of your extension. It looks like your fix actually introduced the bug in SingleFile.

BTW, when your extension is installed on my machine, I see white flashes when refreshing pages on Github. This might be related to this issue. I use Firefox Nightly.

[jaatroko]

While it may have worked with the conflict with SingleFile (did you test with light theme?), the color-scheme property cannot be removed without breaking the workaround.

Let me elaborate a bit on the comments (and content) of the workaround commit b4f3cdf. First I determined that there is a CSS-inaccessible layer between the iframe and its content: setting the iframe content background to red results in a red screen always, but setting instead the iframe background to red results in a white screen on affected sites when using a dark theme and a red screen otherwise. With this information I stumbled upon the workaround as follows: search the web for CSS and light/dark theme => ah-ha! color-scheme property, what's this? => let's try it => seems to work with some combinations, though I'm not quite sure why.

Originally I did not test all the color-scheme combinations. I did that now (Firefox 102) with an unaffected "normal" site (www.example.com) and an affected (presumably those that conform to browser light/dark theme) site (this issue page) with the following results:

div+iframe	iframe content	www.example.com	this issue page
normal	normal	ok	white screen with dark theme
normal	light	ok	white screen with dark theme
normal	dark	black screen	black screen with light theme
normal	light dark	black screen with dark theme	ok
light	normal	ok	ok
light	light	ok	ok
light	dark	black screen	black screen
light	light dark	black screen with dark theme	black screen with dark theme
dark	normal	white screen	white screen
dark	light	white screen	white screen
dark	dark	ok	ok
dark	light dark	white screen with light theme	white screen with light theme
light dark	normal	ok	white screen with dark theme
light dark	light	ok	white screen with dark theme
light dark	dark	black screen	black screen with light theme
light dark	light dark	ok	ok

So there are in fact four combinations with which the workaround works. The color-scheme documentation is a bit vague, but I would say for an addon with fixed colors (determined by addon preferences) the semantically correct value would be either "normal" or "light dark", so that makes "light dark" the one to use.

Looking at the results it seems that when the color-scheme of the iframe (possibly inherited from the enclosing page) and the iframe content disagree, Firefox 102+ tries to "fix" it by setting the background to white or black, when the background (probably) should be transparent like it was for Firefox 101 and earlier.

[jaatroko]

BTW, when your extension is installed on my machine, I see white flashes when refreshing pages on Github. This might be related to this issue. I use Firefox Nightly.

This could be caused by the iframe content CSS not being applied immediately, resulting in a transient "light dark"-"normal" combination from the table above.

[MrKrzYch00]

Is iframe really necessary? Wasn't absolutely positioned div enough to show the visited link information? (just asking, having no clue myself)
What's also interesting to me is that dark reader addon still works properly after whatever they did change in ff 102, just this strange iframe issue. (not like it uses same methods, but still).

EDIT: Sorry, wrong button.

[jaatroko]

Is iframe really necessary?

Purely for layout, no. For privacy protection and resistance to tampering, yes. If the addon UI elements are directly in the page DOM, then the page javascript can (maliciously, carelessly, or otherwise) a) change the UI elements and b) read their content. The content of the elements can include private information, in the case of LSR link visit/bookmarked/open status and visit time. A closed shadow DOM is supposed to offer the same protections, but apperently it does not, not quite anyway. See issue #7 for more information.

[MrKrzYch00]

I see. So not only this method is not perfectly secure but we now also have Firefox behave incorrectly when it's used in conjunction with certain Firefox personalization, like themes.

[jaatroko]

Version 3.17 now available from AMO. It uses the "light"-"normal" color-scheme combination, which should fix the SingleFile issue and the refresh-flickering, and also be more robust with other similar situations (provided that Firefox does not change its behavior about this).

I will still leave this issue open for a few weeks so that it is easier to find in case of possible problems that are not covered by this fix.

[101Monkey]

Just updated to LSR v3.17, and I confirm that it does fix the problem with SingleFIle. Thank you so much! :-)

[jaatroko]

Looking at the results it seems that when the color-scheme of the iframe (possibly inherited from the enclosing page) and the iframe content disagree, Firefox 102+ tries to "fix" it by setting the background to white or black, when the background (probably) should be transparent like it was for Firefox 101 and earlier.

I'm beginning to understand the reasoning here. It is about the default document colors, the color of the page "canvas".

In theory, the coloring of unstyled (with CSS, or with HTML color properties before CSS) documents has always been up to the browser (or the user of the browser). E.g. Netscape Navigator in the nineties had black-on-grey default colors, at least on some platforms. But then, now a long time ago, black-on-white (with blue links and purple visited links) became the de-facto standard default color scheme. Where this becomes problematic is when website authors specify colors only for some elements and assume that everything left unstyled is black-on-white.

Then more recently light/dark theming gains popularity, and the new (implemented 2019 and later) CSS color-scheme property is added. In theory there should be no problems just changing the page color scheme according to the theme, but due to the assumptions mentioned above there needs to be the default/legacy value "normal", which is in effect equivalent to "light".

The default background of an iframe is transparent (like it is for a normal div), meaning that the iframe content page is in effect drawn on the "canvas" of the page containing the iframe. However, the enclosing page and the iframe content may not have any relation to each other, so light/dark-theming the enclosing page can cause problems if the (implicit, in case of "normal"/default) color-scheme of the iframe content disagrees with it. In this case Firefox 102+ inserts a second "canvas" between the iframe and its content, colored white or black according to the (active) color-scheme of the iframe content. Unfortunately this breaks designs that rely on transparent iframes.

I don't know whether this change in Firefox 102 is the right thing to do, as it breaks existing functionality, but it does seem to have a logic behind it. And, being intentional, it may not be a "bug" in that sense.

[MrKrzYch00]

I was searching their bugzilla a bit before and stumbled upon this: https://bugzilla.mozilla.org/show_bug.cgi?id=1738380 ("Figure out what we want to do wrt color-scheme and iframes.")
It even targets: "Target Milestone: --- → 102 Branch" so it may be related to this issue.

[jaatroko]

After reading that bug report, as well as the linked w3c/csswg-drafts#4772, https://www.w3.org/TR/css-color-adjust-1/#color-scheme-effect and https://fvsch.com/transparent-iframes, this seems to be exactly it. If I was an actual, full-time web developer, then maybe I would know more about what is happening in the web standards world, because what I was able to reverse-engineer above about Firefox behavior is exactly what was added to the CSS spec.

As Firefox 102 is doing what the CSS spec says it should do, this is technically a LSR bug, so updating the labels accordingly.

Reading through section 2 of the CSS spec (the second link above) it seems that to be safe the div+iframe color-scheme should be "light only" instead of just "light" so it cannot be overridden. I will publish a new version with this change. As we are dealing with spec-conformant behavior, I can be reasonably confident that this fixes the issue "permanently", so no need to keep the issue open for better visibilty.

[jaatroko]

Version 3.18 now available from AMO.