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

Status: RESOLVED INVALID

(Core :: Layout, defect)

Description

[Lexi Robinson]

Attachment: 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

Comment 1

[Lexi Robinson]

Attachment: Correct positioning

Comment 2

[Lexi Robinson]

Attachment: Offending styles

Comment 3

[Lexi Robinson]

Attachment: Example Page

Comment 4

[Lexi Robinson]

This was reported by a customer running Windows, then verified on Linux and OS X.

Comment 5

[Loic]

Attachment: testcase 1 (with "-webkit-filter")

Comment 6

[Loic]

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?

Comment 7

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (simplified, unprefixed)

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.

Comment 8

[Daniel Holbert [:dholbert]]

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!

Comment 9

[Daniel Holbert [:dholbert]]

(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")

Comment 10

[Lexi Robinson]

(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.