SVG context paints incorrectly inherited by <marker> element
Categories
(Core :: SVG, defect)
Tracking
()
People
(Reporter: szager, Unassigned)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression)
Attachments
(2 files)
actual.png
User Agent: Mozilla/5.0 (X11; CrOS x86_64 14541.0.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36
Steps to reproduce:
Open WPT test case paint-context-001.svg in firefox browser:
Actual results:
<marker>'s are painted with blue stroke and lime fill
Expected results:
<marker> should be painted with black stroke and no fill
Cross-posting from:
https://github.com/web-platform-tests/wpt/issues/44771
I'm currently implementing context-fill and context-stroke support for chromium (https://crbug.com/367737); expected.png is rendered by tip-of-tree chromium with my work in progress patch applied. actual.png is from stable firefox.
|
||
Comment 4•7 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::SVG' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Note that I'm planning to land a change to the existing WPT to fix the test, which currently passes on Firefox:
https://wpt.fyi/results/?label=master&label=experimental&aligned&q=paint-context-001.svg
... but will start failing when the test change lands.
|
||
Comment 6•7 months ago
•
|
||
#1 Regression window (The inside of the square at both ends is filled in black with brack border, i.e., black square):
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=bbd4db7fae199c702a470fa953c830aef3432a47&tochange=c03e05cad1390acfdb74e1085503396522b8cbbb
#2 Regression window (The inside of the square at both ends is filled in green with blue border):
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=45cd9ed42ad7f9e8f3b477c99142ec710aa43a09&tochange=9a4dbcc711edd4ef9585e4376020fef0e74fe2df
|
|
||
Updated•7 months ago
|
On further consideration, the WPT in question will continue to pass after my change, but this is still a bug in mozilla's implementattion. Perma-link to reproduction:
|
||
Comment 8•7 months ago
|
||
I think this is likely a duplicate of bug 1810811
(In reply to Robert Longson [:longsonr] from comment #8)
I think this is likely a duplicate of bug 1810811
It is related, but it's not a duplicate. Most likely this bug was introduced while fixing bug 1810811.
|
||
Comment 10•7 months ago
•
|
||
(In reply to szager from comment #3)
I'm currently implementing context-fill and context-stroke support for chromium (https://crbug.com/367737)
This is kind of a side point, but... Why? I'm not sure you want to do that...
Our intent is (and has always been) that context-fill and context-stroke would be ripped out and replaced by the standardized (but not-yet-implemented) version that we had in our heads for a while and ultimately arrived (in spec form for now) in bug 1812163. That's the whole reason these properties are internal-only in Firefox -- the were good enough to serve a narrow purpose that we needed, but they weren't sufficiently general to be something we'd advocate baking into the web platform. Bug 1812163 captures the "better" version that we settled on (though we still need to implement it). And we made them internal-only so that we'd have the ability to do a search-and-replace on a limited number of repos to modernize to the new thing, once we've got it ready, and then we can safely rip out the implementation of the old/internal thing.
|
Reporter | |
Comment 11•7 months ago
|
||
(In reply to Daniel Holbert [:dholbert] from comment #10)
(In reply to szager from comment #3)
I'm currently implementing context-fill and context-stroke support for chromium (https://crbug.com/367737)
This is kind of a side point, but... Why? I'm not sure you want to do that...
Our intent is (and has always been) that
context-fillandcontext-strokewould be ripped out and replaced by the standardized (but not-yet-implemented) version that we had in our heads for a while and ultimately arrived (in spec form for now) in bug 1812163. That's the whole reason these properties are internal-only in Firefox -- the were good enough to serve a narrow purpose that we needed, but they weren't sufficiently general to be something we'd advocate baking into the web platform. Bug 1812163 captures the "better" version that we settled on (though we still need to implement it). And we made them internal-only so that we'd have the ability to do a search-and-replace on a limited number of repos to modernize to the new thing, once we've got it ready, and then we can safely rip out the implementation of the old/internal thing.
This is the first I've heard of link-parameters, so I'm not sure I can give a satisfactory response. But if and when link-parameters ship, it doesn't necessarily follow that context-fill/stroke will be deprecated in the SVG spec. That's a different conversation, and from what I can tell one that hasn't been started; the closest I could find was this 2017 issue. The MDN docs don't directly refer to context-fill/stroke, but it's still listed in the "Browser Compatibility" section. It would be good to get some clarity on this.
|
|
||
Comment 12•7 months ago
|
||
Whoops, sorry - it's been too long since I thought about this, and I conflated them with an associated internal feature. I think you can disregard comment 10; sorry for my confusion there.
(The thing that we're ultimately deprecating is -moz-context-properties which (in Firefox, for frontend content) provides a way to magically propagates fill-->context-fill etc. from outside an SVG image to inside an SVG image. That's the thing that we're aiming to replace with the Linked Parameters feature. But indeed, context-paint and context-fill are their own well-behaved standards-compliant thing for e.g. <marker>, distinct from that particular special image-boundary-crossing behavior.)
|
|
||
Updated•7 months ago
|
Description
•