Open Bug 1426919 Opened 2 years ago Updated 8 months ago

`position: fixed` element inside element with 'filter' scrolls with the body rather than remaining actually fixed

Categories

(Core :: Layout, defect, P3)

58 Branch
defect

Tracking

()

People

(Reporter: impinball, Unassigned)

References

Details

(Keywords: parity-chrome, parity-edge, regression)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID: 20171211020921

Steps to reproduce:

Go to this page [1]. It should render and visibly work exactly like [2], and does in Safari. Note that the value of `filter` is irrelevant here. All that matters is that it exists and is valid.

[1]: data:text/html,%3Cmeta charset%3Dutf-8%3E%3Cdiv style%3D"height%3A200%25%3Bfilter%3Abrightness(1)%3B"%3E%3Cdiv style%3D"background-color%3Ablue%3Bheight%3A100px%3Bposition%3Afixed%3Bleft%3A0%3Bright%3A0%3B"%3E%3C%2Fdiv%3E%3C%2Fdiv%3E

[2]: data:text/html,%3Cmeta charset%3Dutf-8%3E%3Cdiv style%3D"height%3A200%25"%3E%3Cdiv style%3D"background-color%3Ablue%3Bheight%3A100px%3Bposition%3Afixed%3Bleft%3A0%3Bright%3A0%3B"%3E%3C%2Fdiv%3E%3C%2Fdiv%3E


Actual results:

The blue box is fixed relative to its container. (i.e. what I'd expect out of `position: absolute`)


Expected results:

The blue box should be fixed relative to the viewport.
Couple notes:

- Although I didn't test it in Chrome, I'm 99.9% sure it'd work like it does in Safari. I originally discerned it from an extension I use, and where I used a similar one in Chrome that worked the same way (CSS `filter`), it didn't break any sites that use `position: fixed`.
- The data URIs are actually this source code:

```html
<!-- 1 -->
<meta charset=utf-8><div style="height:200%;filter:brightness(1);"><div style="background-color:blue;height:100px;position:fixed;left:0;right:0;"></div></div>

<!-- 2 -->
<meta charset=utf-8><div style="height:200%"><div style="background-color:blue;height:100px;position:fixed;left:0;right:0;"></div></div>
```

(Yes, they're missing the doctype declaration, but that's irrelevant for this test case. I included it in some of my local tests in reducing the test case, and it had no effect.)
regression since 39.
Status: UNCONFIRMED → NEW
Component: Untriaged → Layout
Ever confirmed: true
Keywords: regression
Product: Firefox → Core
Whiteboard: [parity-Chrome][parity-Edge]
That looks very intended looking at bug 1125767...
From reading the comments of that bug, should I bring it up in the relevant spec's repo? I'll note that Chrome/Safari's behavior would be better for night mode extension writers (e.g. Deluminate), who need to be able to invert most CSS colors to provide the "night mode".
@emilio: Note that this is about `position: fixed`, not `position: absolute`.
I think there was a recent (last 2 or 3 months?) spec discussion in the CSS working group about this, and it might have come to a conclusion that the behavior should be different for 'filter' on the root element (and maybe also <body>).
Summary: `position: fixed` element scrolls with the body rather than remaining actually fixed → `position: fixed` element inside element with 'filter' scrolls with the body rather than remaining actually fixed
David, should I post a comment there about this bug?
[ Triage 2017/02/20: P3 ]
Priority: -- → P3
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Whiteboard: [parity-Chrome][parity-Edge]

Any update about that bug? It breaks all "Dark Mode" extensions, which works fine in Blink based browsers.

You need to log in before you can comment on or make changes to this bug.