RESOLVED DUPLICATE of bug 68090 125788
svgbgspecificity SVG background override from higher specificity renders incorrectly
https://bugs.webkit.org/show_bug.cgi?id=125788
Summary SVG background override from higher specificity renders incorrectly
Adam Horton
Reported 2013-12-16 10:57:17 PST
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
Adam Horton
Comment 1 2013-12-16 10:58:21 PST
Please refer to http://codepen.io/anon/pen/rldLw for reproduction. Initial comment is based on this code sample.
Tamas Gergely
Comment 2 2014-02-13 05:38:44 PST
(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
Comment 3 2014-02-21 01:37:42 PST
(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
Comment 4 2014-03-13 19:50:48 PDT
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 ***
Note You need to log in before you can comment on or make changes to this bug.