WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
REOPENED
189256
feFlood with explicit size in CSS filter doesn't render
https://bugs.webkit.org/show_bug.cgi?id=189256
Summary
feFlood with explicit size in CSS filter doesn't render
Simon Fraser (smfr)
Reported
2018-09-03 21:59:32 PDT
Attached test case doesn't render in Safari; it does in FF and Chrome (differently). Oddly, toggling dismay:none on the SVG changes behavior.
Attachments
Testcase
(806 bytes, text/html)
2018-09-03 21:59 PDT
,
Simon Fraser (smfr)
no flags
Details
unclipped filtered element
(880 bytes, text/html)
2023-04-10 10:53 PDT
,
Said Abou-Hallawa
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Simon Fraser (smfr)
Comment 1
2018-09-03 21:59:52 PDT
Created
attachment 348805
[details]
Testcase
Ahmad Saleem
Comment 2
2023-04-08 06:22:47 PDT
I am able to reproduce this bug in Safari 16.4 and green rect is on 0,0 while Chrome Canary 114 and Firefox Nightly 113 does not start from 0,0 but has margin around it.
Said Abou-Hallawa
Comment 3
2023-04-10 10:53:25 PDT
Created
attachment 465833
[details]
unclipped filtered element I think the display in WebKit is more correct than Chrome and FireFox. The default filterRegion of the SVGFilter is { -10%, -10%, 110%, 110% }. Because the filtered element dimension is { 100, 100 }, the filterRegion will be extended 10 pixels from all directions. In WebKit, this is drawn with no clipping. But in Chrome and FireFox, the top and the left extended areas are clipped. See the attached new test case where a filtered element is drawn and an another overlay element with the same dimension is drawn on top of it. The overlay element only draws the border.
Simon Fraser (smfr)
Comment 4
2023-04-10 11:09:01 PDT
I don't think this config changed; if our rendering differs from Chrome and Firefox and we think the behavior is correct, we should open a spec issue to have the spec clarify behavior. It's not clear to me that WebKit behavior is correct.
Said Abou-Hallawa
Comment 5
2023-04-10 17:26:51 PDT
(In reply to Simon Fraser (smfr) from
comment #4
)
> I don't think this config changed; if our rendering differs from Chrome and > Firefox and we think the behavior is correct, we should open a spec issue to > have the spec clarify behavior.
But the specs is clear for applying an SVGFilter on an SVGElement. The geometry of the filterRegion is { -10%, -10%, 110%, 110% }, see
https://drafts.fxtf.org/filter-effects/#filter-region
. The problem happens when applying the SVGFilter to an HTMLElement. Do we apply the filterRegion geometry outside the HTMLElement border box?
> > It's not clear to me that WebKit behavior is correct.
I am not sure why the rendering of Chrome and FireFox is correct. They clip the top and left filter extension and they keep the right and the bottom. And I think we need at least to retitle this bug and preferably close this one and open a new one. The original bug was fixed (not drawing the filter itself). We now want to discuss: The filterRegion geometry of the SVGFilter when applied on an HTMLElement.
Simon Fraser (smfr)
Comment 6
2023-04-10 17:56:33 PDT
I’m OK with doing that.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug