New issue
Advanced search Search tips

Issue 883151 link

Starred by 3 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 3
Type: Bug-Regression



Sign in to add a comment

column-span:all doesn't work when inside of an element with filter

Reported by ldavidba...@gmail.com, Sep 12

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64; rv:64.0) Gecko/20100101 Firefox/64.0

Steps to reproduce the problem:
1. look at attached testcase

What is the expected behavior?
As in Edge, the purple "C" box (which has column-span:all) should run the entire width of the yellow box, with the "A" and "B" above it.

What went wrong?
column-span is disabled because the blue box has 'filter: blur(1px)' on it.  Per https://drafts.csswg.org/css-multicol/#column-span it would be expected that column-span doesn't work across elements that establish a new block formatting context, but filter doesn't do that per https://drafts.fxtf.org/filter-effects-1/ .  (It establishes a stacking context and a containing block for absolute- and fixed-positioned elements, but those are different.)

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 69.0.3497.92  Channel: n/a
OS Version: 10
Flash Version: 

Edge shows the expected results.  Safari doesn't have this bug, but it does have a different bug where the "D" part disappears.  I expect this will work in the upcoming Firefox implementation for which I'm currently doing the code review (but haven't tested).
 
tc.html
334 bytes View Download
The webkit bug on the testcase is https://bugs.webkit.org/show_bug.cgi?id=189534
Labels: Needs-Triage-M69
Cc: pbomm...@chromium.org e...@chromium.org
Components: -Blink>Layout Blink>Paint
Cc: ajha@chromium.org
Labels: -Type-Bug -Pri-2 ReleaseBlock-Stable M-69 Target-70 Target-71 RegressedIn-68 M-70 FoundIn-71 FoundIn-70 Target-69 FoundIn-69 OS-Linux OS-Mac Pri-1 Type-Bug-Regression
Owner: mstensho@chromium.org
Status: Assigned (was: Unconfirmed)
Able to reproduce the issue on the latest canary 71.0.3550.3 and on the latest stable 69.0.3497.92 on Windows-10, Mac OS 10.13.6 and Linux Debian Rodete.

Regressed in M-68 on Chrome and test case behaves the same on FF.

Last good build: 68.0.3440.23
First bad build: 68.0.3440.24

Changelog:

https://chromium.googlesource.com/chromium/src/+log/68.0.3440.23..68.0.3440.24?pretty=fuller&n=10000

Suspecting: https://chromium-review.googlesource.com/c/chromium/src/+/1097955.

mstensho@: Could you please take a look at these crashes.

Note: Adding RB-Stable for M-69/M-70 for tracking, feel free to remove if this should not be blocking. 
Labels: hasbisect
Cc: mstensho@chromium.org
Labels: -Pri-1 Pri-3
Owner: ----
Status: Available (was: Assigned)
This is deliberate behavior (from an implementation point-of-view), introduced for filters in https://chromium-review.googlesource.com/1089336

We first introduced this rule for transforms, way back:
https://codereview.chromium.org/1908393002

Filters (like transforms) are containing blocks for out-of-flow positioned descendants. In our implementation, spanners need the multicol container to be the containing block (it's also sort of implied by the spec, right?). In some respects, this (not letting filtered and transformed element contain everything inside) causes trouble in our engine.

I can't really say that I'm 100% sure it would be wrong from a spec point-of-view to allow spanners inside filtered elements (or transforms), though.

In any case, I doubt that we're going to fix this in the current Blink layout engine.
Labels: -ReleaseBlock-Stable
Removing RB-Stable as per C#7 as this seems to be deliberate change.

Sign in to add a comment