Open Bug 1426919 Opened 6 years ago Updated 2 years ago

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

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Version:
58 Branch
Type:
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.)
Keywords: parity-chrome, parity-edge
Whiteboard: [parity-Chrome][parity-Edge]

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

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.