1386470 - Blur filter causes horizontal scrollbar to show up (by inducing a new containing block for offscreen fixed-pos descendant)

Status: RESOLVED DUPLICATE of bug 1226095

(Core :: Layout, defect, P3)

Description

[Wyatt Childers]

Attachment: Broken Page

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170612122310

Steps to reproduce:

Please see the attached files for an example of the broken page setup.


Actual results:

When a filter: blur is applied to an element hidden via width, the element becomes visible on the page.


Expected results:

When a filter: blur is applied to an element hidden via width, the element should remain hidden.

Comment 1

[Wyatt Childers]

Attachment: Working Page (No blur applied)

Comment 2

[Wyatt Childers]

Just tested this with stylo enabled nightly, and it's still a problem.

Comment 3

[Jet Villegas (inactive)]

Does this still occur? Your test file renders the same for me on Firefox Nightly, Chrome, and Safari.

Comment 4

[Wyatt Childers]

Hi Jet, sorry for the delay. Yes I still see this occurring. Look at the bottom of the tab, a horizontal scrollbar should appear on the broken page, because the element tucked away on the right became visible; this does not happen on Chrome.

Comment 5

[Wyatt Childers]

It's also worth noting the element on the right isn't truly hidden because of the default body rendering rules. If you were to add the style rule:

body {
  margin: 0px;
}

The right element would truly be 100% hidden and this issue still occurs in that situation.

Comment 6

[Daniel Holbert [:dholbert]]

The Firefox/Chrome difference here is basically a question of whether filters establish a fixed-pos containing block.

They do establish a fixed-pos containing block in Firefox, whereas they don't in Chrome.  So this is basically a duplicate of bug 1226095 (which is a case where we're following the spec, modulo the spec-tweak that's tracked in the spec github-issue linked on that bug -- https://github.com/w3c/fxtf-drafts/issues/11 )

Comment 7

[Daniel Holbert [:dholbert]]

Also, for the record -- despite the bug title, your "width:0 element" is *not* actually "displaying" here.

Rather, its fixed-pos descendant is displaying. And it displays in every browser, as long as it's positioned on-screen (or in scrollable overflow).

In your reference case, it is positioned just outside the viewport (because it derives its position from its DOM-tree parent, which is the zero-width div at the far right of the flex container).  And it's not reachable by scrolling the viewport, because its fixed containing block *is* the viewport.

In contrast: in your testcase, it's still positioned at the same spot, but its fixed containing block is the blurred <div> -- so it creates some scrollable overflow on that div, which the div's scrollable ancestor (the viewport) dutifully allows you to reach via scrolling.

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: working page #2 (with blur *and* with additional "overflow:hidden")

For the record, here's a modified version of the "Broken Page" attachment, with "overflow-x: hidden" added to the blurred div.  This might be what you want to use as a workaround on your page, if this happens to be causing trouble for you.

As noted above: the blurred div forms the containing block for the fixed-pos descendant, in Firefox.  And that descendant happens to be offscreen, so it creates scrollable overflow, unless we put overflow-x:hidden on one of its container boxes, like I'm doing here.

The other "overflow:hidden" that you've got deeper in the frame tree doesn't help, because that element is not actually the parent of the fixed-pos thing in the box tree.