WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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
Add attachment
proposed patch, testcase, etc.
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.
Top of Page
Format For Printing
XML
Clone This Bug