Bug 125788 (svgbgspecificity)
| Summary: | SVG background override from higher specificity renders incorrectly | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Adam Horton <digitalicarus> |
| Component: | CSS | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | Normal | CC: | pdr, tgergely.u-szeged |
| Priority: | P3 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | All | ||
| OS: | All | ||
| URL: | http://codepen.io/anon/pen/rldLw | ||
Adam Horton
The SVG should match the png. The extra specificity doesn't seem to change the background. Even if both the svg specific backgrounds are changed to the filled square they seem to mysteriously retain the unfilled source. If one inspects the divs and opens a new tab to the data URI in chrome it displays the correct svg source, so there's something going on with the css here.
This problem occurs in both Chrome and Safari but the code works as expected in FireFox.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Adam Horton
Please refer to http://codepen.io/anon/pen/rldLw for reproduction. Initial comment is based on this code sample.
Tamas Gergely
(In reply to comment #0)
> The SVG should match the png. The extra specificity doesn't seem to change the background. Even if both the svg specific backgrounds are changed to the filled square they seem to mysteriously retain the unfilled source. If one inspects the divs and opens a new tab to the data URI in chrome it displays the correct svg source, so there's something going on with the css here.
>
> This problem occurs in both Chrome and Safari but the code works as expected in FireFox.
If you replace the "em" unit in the SVG to "cm" you will see the color boxes. It seems that WK ignores the em length modifier, thus creates a 1px x 1px image with 1px borders resulting in gray boxes. The result is the same if the svg is loaded in an <img/> tag, but loading the svg directly seems to work correctly.
Tamas Gergely
(In reply to comment #2)
> (In reply to comment #0)
> > The SVG should match the png. The extra specificity doesn't seem to change the background. Even if both the svg specific backgrounds are changed to the filled square they seem to mysteriously retain the unfilled source. If one inspects the divs and opens a new tab to the data URI in chrome it displays the correct svg source, so there's something going on with the css here.
> >
> > This problem occurs in both Chrome and Safari but the code works as expected in FireFox.
>
> If you replace the "em" unit in the SVG to "cm" you will see the color boxes. It seems that WK ignores the em length modifier, thus creates a 1px x 1px image with 1px borders resulting in gray boxes. The result is the same if the svg is loaded in an <img/> tag, but loading the svg directly seems to work correctly.
After some debugging I've figured out the following:
When the Page object for the main document is loaded, its Settings object is created with 0 as m_defaultFontSize, but the default font size is later set to a non-zero value.
When the image is created, its Page object creates a new Settings object with a 0 valued default font size, but it is not set to non-zero value later.
Should we propagate the default settings to all Page objects, and not set it only to the main one?
Philip Rogers
Thank you for taking the time to file this. This is another example of wkbug.com/68090
As for fixing it, I agree with #3: we should use the browser defaults.
*** This bug has been marked as a duplicate of bug 68090 ***