1438774 - "filter" applied to "html" element breaks height calculations

Status: RESOLVED DUPLICATE of bug 1423746

(Core :: CSS Parsing and Computation, defect, P3)

Description

[Steven Noonan]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36

Steps to reproduce:

I've reproduced this issue on Firefox 58.0.2, 59.0b9, and 60.0a1 (2018-02-13 nightly).

Small test case here (actually reduced from bugzilla.mozilla.org's own HTML/CSS layout): https://elbereth.uplinklabs.net/test.html

I found this issue by using the Dark Reader extension, which applies a "-webkit-filter" CSS property to the "html" root element. I noticed what while viewing multiple different sites (but not all), it would cause the page to render as completely black instead of as inverted. Digging through the developer console, I found that percent-based height calculations were being broken by the "filter" property (note that both "-webkit-filter" and "filter" have identical behavior here, so I'm just going to refer to it as "filter" from here on).


Actual results:

If a CSS "filter" property such as "filter: invert(100%)" is applied to the "html" element, then the height calculations for children will break (e.g. div#wrapper is set to "height: 100%" but ends up with a height of 0px).


Expected results:

There are two ways to make the filter work:

- If the same "filter" is applied to the "body" element instead, then the intended behavior happens.
- If the "html" element is given a "height" value in the CSS (e.g. "100%"), then the filter applies correctly and everything renders fine.

It seems that the default height of "html" is calculated as 0px, but this doesn't matter unless a filter gets applied.

This differs from Chrome's behavior, where "filter" can be applied to the "html" element without explicitly defining the height of "html".

I've left the relevant filter properties commented out in the CSS on the test case, so you can check them in the developer console and check/uncheck at will (I didn't know about this feature until just now, actually!).

Comment 1

[Abe - QA (:Abe_LV)]

I tested this on Fx58.0.2 with dark reader addon and it is reproducible. Unlike chrome, the whole page becomes dark on Firefox.

Comment 2

[Steven Noonan]

By the way, I found some other position/size calculations that get confused when a filter/-webkit-filter is active on the "html" element, even on pages that don't turn black because of the height:100% calculations.

I have the Imagus extension installed, which adds elements to the page to show previews for linked images and videos. It basically shows an img/video element that dereferences links that your mouse cursor hovers over, and the preview elements follow your cursor around while it stays over the link. When Dark Mode's CSS is active on the "html" element (i.e. "-webkit-filter: invert(100%)"), the hovering image preview can't follow the mouse cursor if you scroll down on the page. The position of the preview elements is restricted to the top of the document, within a bounding region the size of the viewport. If I turn Dark Mode off (killing the "-webkit-filter" on "html") then the position calculations for the hovering preview work properly and it can follow my cursor again, regardless of how far I scroll down the page. You can repro this by installing Imagus and then going to reddit: try hovering over image/video links and try again after scolling down a bit.

Comment 3

[Jet Villegas (inactive)]

[ Triage 2018/02/21: P3 ]

Comment 4

[Steven Noonan]

Sorry to bump this bug report, but it's now been a few days short of a full year since I filed this bug. This still hasn't been fixed (currently using Firefox 65.0) and this still affects me.

Since this was originally posted, The Dark Reader extension added different mode options for darkening web pages: "Filter", "Filter+", "Static", and "Dynamic".

Filter and Filter+ are the two modes affected by this issue. I found a more concrete example for what I mentioned in comment 2 above. The symptoms differ from what I described in the initial report, but I believe they stem from the same problem (some kind of height/position calculation is busted):

1. Install The Dark Reader, using either Filter or Filter+.
2. Install Imagus.
3. Open any page on Wikipedia with images.
4. Scroll the viewport down, and note that hovering over images causes Imagus to place the larger image in the wrong position (the top of the page, outside the viewport if you scroll far enough).

For the above, my hack to use a userstyle of "html { height: 100%; }" doesn't affect it in any way.

The other two modes (Static and Dynamic) work, but aren't as useful most of the time. Static usually creates an ugly result unless the page is extremely simple and has no gradients or anything. Dynamic creates beautiful results, but they take a lot of CPU time to produce and dramatically reduce responsiveness of the pages (presumably due to use of DOM MutationObserver).

Comment 5

[Emilio Cobos Álvarez [:emilio]]

See bug 1423746 for the discussions. The tl;dr is that we implemented what the spec said at the time, and people are figuring out what it should do in https://github.com/w3c/fxtf-drafts/issues/282.