| Summary: | background-image/webkit-mask-image doesn't update properly with SVG url fragments | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Christopher Swasey <christopher.swasey> |
| Component: | CSS | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW --- | ||
| Severity: | Normal | CC: | koivisto, sabouhallawa, simon.fraser, smoley, webkit-bug-importer, zalan |
| Priority: | P2 | Keywords: | InRadar |
| Version: | Safari Technology Preview | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
|
Description
Christopher Swasey
2020-12-02 20:30:07 PST
I should clarify: I first reduced this examples locally before copying them into the fiddles. JSFiddle might occasionally mask the appearance of the bug(s), but, so far, the buggy behavior is _always_ present with just a static HTML file. The background color change (and the `currentcolor` oddity) seems to have been a bit of a red herring. It turns out that `color`—regardless of whether `background-color` is `currentcolor`—is one of the few CSS properties that don't seem to resolve the bug with a mutation. So far I've tried `opacity` (different values), `transform` (different scales), `font-size` (different sizes, even though there's no text content), `border-color` (different colors, even with `border-width: 0`) and changing them all suffices to avoid the bug. So, my work around for my use case (icons), at least: each mask class gets a unique `border-color`. Thanks for filing, I can reproduce cases 1-4 on Safari 13.1.3 - STP 116. I was not able to reproduce Case 5 even with a local html file on either build. Not sure if this is directly related, possibly a clue, or maybe a separate bug entirely, but I recently noticed—when playing with an app I already had opened in Safari on my iPhone, after leaving the house—that previously "unseen" fragments in an already-loaded SVG file don't render if the original file is inaccessible. Already-seen fragments from the very same file continued to work fine (with my workaround as discussed above.) |