Closed Bug 1311070 Opened 6 years ago Closed 6 years ago

-webkit-filter breaks position: fixed with layout.css.prefixes.webkit=true

Categories

(Core :: Layout, defect)

49 Branch
x86_64
All
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: lexi, Unassigned)

References

()

Details

(Keywords: regression)

Attachments

(4 files, 2 obsolete files)

Attached image Improper positioning
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:49.0) Gecko/20100101 Firefox/49.0
Build ID: 20160922113459

Steps to reproduce:

Example here: http://codepen.io/Lexicality/pen/NROYPg

Having several position: fixed elements on the page and `-webkit-filter: contrast(105%);` on the bodoy


Actual results:

Fixed position elements are no longer fixed


Expected results:

Fixed position elements should remain where they should be
OS: Unspecified → All
Hardware: Unspecified → x86_64
Attached image Correct positioning
Attached file Offending styles (obsolete) —
Attached file Example Page (obsolete) —
This was reported by a customer running Windows, then verified on Linux and OS X.
That's due to the support of -webfix properties through layout.css.prefixes.webkit=true. If you disable that pref in about:config, the normal rendering is back.

Daniel, your opinion?
Component: Untriaged → Layout
Depends on: 1213126
Flags: needinfo?(dholbert)
Product: Firefox → Core
Summary: -webkit-filter breaks position: fixed → -webkit-filter breaks position: fixed with layout.css.prefixes.webkit=true
Keywords: regression
Looks like this is simply a difference in how Chrome & Firefox treat the "filter" property (regardless of whether it's prefixed).

Here's a more targeted testcase that. In Firefox, the two lines of text are superimposed. In Chrome, "FIXED-POS" is at the top of the page.
Attachment #8802196 - Attachment is obsolete: true
Attachment #8802197 - Attachment is obsolete: true
Attachment #8802244 - Attachment description: 1311070.html → testcase 1 (with "-webkit-filter")
Attachment #8802277 - Attachment description: testcase 2 (unprefixed) → testcase 2 (simplified, unprefixed)
Looks like what we're doing is correct, according to the spec (and Chrome is non-conforming on their "filter" implementation).

This was previously discussed in bug 1281068.  See bug 1281068 comment 14 in particular, for the working-group resolution that we're honoring.  I guess Chrome hasn't implemented that behavior yet. (And the resolution may not have made it into the spec yet, since https://github.com/w3c/fxtf-drafts/issues/11 is still open. I've just pinged the spec editors on that bug.)

--> Resolving as INVALID, since Firefox is correct here.

(Ideally, the site should be updated to accommodate the possibility that the filtered element may be an abs-pos/fixed-pos containing block.  The easiest way to fix this is to move this "body" style to apply to "html" instead -- because that's actually the element that you want to be the fixed-pos containing block. i.e. you want to drop the .body filter rule, and instead use:
  .html {
    -webkit-filter: contrast(105%);
    filter: contrast(105%);
  }

Lex, any chance you're a developer involved with this site & have the ability to make that change? Thanks for reporting this, BTW!
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Flags: needinfo?(dholbert) → needinfo?(lexi)
Resolution: --- → INVALID
(In reply to Daniel Holbert [:dholbert] from comment #8)
> Lex, any chance you're a developer involved with this site & have the
> ability to make that change? Thanks for reporting this, BTW!

(by "this site" I mean "the site in question, for which customers were reporting problems, per comment 4")
See Also: → 1281068
(In reply to Daniel Holbert [:dholbert] from comment #8)

Thanks, that fixes it.
I do consider this very surprising behaviour though, especially since it appears only to be documented in a bug that I somehow wasn't able to find with several searches.
Flags: needinfo?(lexi)
You need to log in before you can comment on or make changes to this bug.