FireFoxInvertColors
FireFoxInvertColors copied to clipboard
Max-Github
Some Inverted pages become 'invisible'
I've hit this issue on some random sites but not investigated more fully because I turned off Inverting, but after having installed Nextcloud 13.0 which has a default theme with some values close to the mid-point and getting a completely blank page I'm digging deeper.
I can't say I fully understand what I'm seeing as-yet but it /seems/ like elements with color values close to #808080 makes text invisble when the filter itself is applied.
Using Firefox 60.0a1 (2018-03-05) (64-bit) on Ubuntu 16.04.
If you can add any insights or investigate that would be helpful.
Follow-up observation: the page doesn't become 'invisible' - the content divs below the header change height to 0!
I just tried the demo, and what I can see is that disabling the following with the Page Inspector:
#content-wrapper { position: absolute; }
Resolved the issue, but I am not sure what is the cause of this though.
This can also be resolved by disabling the "height" for #content-wrapper. Very strange.
Wow, thanks! I was investigating a potential interaction with multiple filters since it seems Nextcloud uses the bootstrap.css extensively. Having the Nextcloud source I was able to grep and found a lot of alpha filters - this one found because when I set a background-color: red for 1 text element it appeared salmon-pink.
Now, your discovery is interesting in that for the last few weeks I noticed in Firefox that when I viewed an image in a tab via a direct link and Invert is on, the image is mis-placed by -50% of it's height - meaning only the lower half of the image is visible.
It sounds like we may have a weird Firefox bug; I'll drop into the Mozilla dev IRC channels see if a developer there can reproduce it - they've been pretty responsive with other bugs I've discovered.
If viewing a direct image URL Firefox wraps it in HTML which includes 3 internal stylesheets.
Removing
<link rel="stylesheet" href="resource://content-accessible/TopLevelImageDocument.css">
brings the image top back into the window but also moves it to the left rather than being centered, and leaves a non-inverted background to the right of the image.
From this I found the 1/2 an image issue is caused by the TopLevelImageDocument.css::img {"bottom: 0" } conflicting with the it's img { margin: auto}.
Setting bottom: inherit solves it but not sure if this is the correct fix for Firefox to apply. Will ask devs.
Discussion in #layout on irc.mozilla.org pointed me to a specification change that was forecast to cause this issue but is apparently behaving 'as intended' !
"filter should be defined to establish a containing block for fixed and absolutely positioned elements" https://github.com/w3c/fxtf-drafts/issues/11
Firefox bug to track fixing this is:
"Filter on the documentElement should not establish a containing block" https://bugzilla.mozilla.org/show_bug.cgi?id=1423746
I've put together a framework to enable applying workarounds for bugs like this. Please take a look and if you're happy with the approach and implementation I'll issue a PR.
https://github.com/iam-TJ/FireFoxInvertColors/commits/bug-workarounds
I need to think about this. As this might have some unintended consequences on other sites.
We might need to use url filtering or content checking to auto-apply the workarounds. Or have a list where people can enter a URL to apply certain "Workarounds".
Remember that the bug here isn't due to sites doing something wrong, it's due to Firefox, so in principle the workarounds.css should only apply to Firefox's own CSS handling.
It may be possible to find a single style or API call that can fix this one but I tried applying various fixes to the html and body elements without success.
The problem here is that the filter operation actually inserts a new, invisible (to the DOM as seen by extensions, dev tools, etc,), container element and moves it out of the documentRoot hierarchy which is why sub-elements that relied on positioning styles set on body suddenly move!
The only other way I can think of is that we use Javascript to iterate over the body.children and copy up any position-related styles from body.styles to them.
I can experiment with that approach if you prefer but I'd like to avoid too much work on something that will be fixed in Firefox soon.
After some experimentation it seems that simply doing:
body { height: 100% }
is sufficient to reset the height from 0 to the correct value.
It solves the issue in the 2 cases we know of and I can't imagine any bad side-effects from it on other pages since the body should be 100% of it's parent window.
I've done a forced update to my branch with this, squashing into 1 commit in the process.
Found a downside to this; On duckduckgo.com the results page loses it's scroll bars so can't scroll to fetch more results. Back to the drawing board!
just to add another test case for future solutions: https://www.deeplearningbook.org/contents/linear_algebra.html becomes black when inverting. body height is 0.
