Closed
Bug 826562
Opened 12 years ago
Closed 12 years ago
SVG Data URL with a "#" character ends up broken (since # is treated as end of start of #reference)
Categories
(Core :: SVG, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: gottfried.haider, Unassigned)
References
Details
(Whiteboard: [webcompat])
Attachments
(1 file)
1.24 KB,
text/html
|
Details |
I am trying to load an SVG file as a Data URL and draw it onto a canvas. Firefox (17) will report the width and height as 0, and the subsequent drawImage call throws NS_ERROR_NOT_AVAILABLE. This works on Chromium.
Note that the SVG includes dimensions, in pixels even. The root element looks like this:
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" id="Layer_1" x="0px" y="0px" width="98.279px" height="25.336px" viewBox="0 0 98.279 25.336" enable-background="new 0 0 98.279 25.336" xml:space="preserve">
I originally filed this as bug 700533 comment 7.
Updated•12 years ago
|
Attachment #697743 -
Attachment mime type: text/plain → text/html
Comment 1•12 years ago
|
||
First step to debug this is to view the data URI directly.
If you do that, you'll see a (somewhat cryptic) error page, about an un-closed tag. (even though it looks like it's closed)
The problem is this hash character:
> data:image/svg+xml;utf8,[---SNIP---]<path fill="#231F20"
^
You have to URL encode it (replace it with %23), or we'll treat everything after it as an ID to be seeked to in the page. (since # has a special reserved meaning in URIs)
If you fix that, your testcase should work. (It does for me, anyway.)
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
Comment 2•12 years ago
|
||
new-link-in-comment-7 |
If you're interested, I actually submitted a proposal to the whatwgmake this "just work", here:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-September/033162.html
But, it ended up fizzling because our existing (strict) behavior is correct, and my proposal was too magical. See e.g. these responses.
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-September/033181.html
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-September/033196.html
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-September/033210.html
(though it looks like Opera & Webkit both still have the bugs that I brought up in that thread, making them less strict & making content developed in their engines potentiaally break in Firefox :-/ )
So -- in the meantime, best to swap out "#" for %23 in data URIs. (and urlencode other special characters as well, for good measure)
Comment 3•12 years ago
|
||
>to the whatwgmake
er "to the whatwg, to make"
Updated•12 years ago
|
Summary: Loading SVG Data URL results in image with no dimensions, drawing to canvas fails → Loading SVG Data URL with a "#" character results in image with no dimensions, drawing to canvas fails
Reporter | ||
Comment 4•12 years ago
|
||
Thank you very much Daniel for looking into this! Sorry for the noise, I indeed forgot to escape the data URL.. maybe the fact that onload was called regardless threw me off a bit.
Summary: Loading SVG Data URL with a "#" character results in image with no dimensions, drawing to canvas fails → Loading SVG Data URL results in image with no dimensions, drawing to canvas fails
Reporter | ||
Updated•12 years ago
|
Summary: Loading SVG Data URL results in image with no dimensions, drawing to canvas fails → Loading SVG Data URL with a "#" character results in image with no dimensions, drawing to canvas fails
Comment 5•12 years ago
|
||
No problem!
Comment hidden (typo) |
Comment 7•9 years ago
|
||
(In reply to Daniel Holbert [:dholbert] (largely AFK until June 28) from comment #2)
> If you're interested, I actually submitted a proposal to the whatwg, to make this
> "just work", here:
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-September/033162.html
Historical note -- the above ^^ mailing-list-archive link seems to be broken now -- but here's an updated link which seems to work:
https://lists.w3.org/Archives/Public/public-whatwg-archive/2011Sep/0100.html
Updated•8 years ago
|
Summary: Loading SVG Data URL with a "#" character results in image with no dimensions, drawing to canvas fails → SVG Data URL with a "#" character ends up broken (since # is treated as end of start of #reference)
Updated•8 years ago
|
See Also: → https://webcompat.com/issues/8784
Updated•7 years ago
|
Updated•7 years ago
|
Flags: webcompat?
Whiteboard: [webcompat]
Comment 11•7 years ago
|
||
Can this bug be reconsidered for web compatibility? It seems all other major browsers support unescaped # in a data uri, except Firefox. While it may be spec-conforming to require escaping, there are lazy developers out there that don't test in Firefox which can lead to broken sites.
Example fiddle: https://jsfiddle.net/c0ak9pq1/16/
Popular StackOverflow issue: https://stackoverflow.com/q/30733607
Comment 12•7 years ago
|
||
Better fiddle highlighting the issue: https://jsfiddle.net/zoyam19h/3/
Comment 13•7 years ago
|
||
@silverwind updated your last fiddle to include Opera https://jsfiddle.net/zoyam19h/6/
Is Firefox slowly turning into the poorer cousin?
Comment 14•7 years ago
|
||
(In reply to silverwind from comment #11)
> Can this bug be reconsidered for web compatibility? It seems all other major
> browsers support unescaped # in a data uri,
Actually, the Chrome developers are trying to change Chrome to match the spec (i.e. to match Firefox), over in https://bugs.chromium.org/p/chromium/issues/detail?id=123004#c59 (see that comment and later comments - lots of ~recent activity there)
See also their announcement at https://bugs.chromium.org/p/chromium/issues/detail?id=123004#c80 and https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/_g_HnAHkMPo
It sounds like they've encountered some issues as a result (in part at Google-owned web properties) and they're doing outreach to fix these and are hoping to continue moving forward.
> there are lazy developers out there
> that don't test in Firefox which can lead to broken sites.
If/when Chrome changes, this will be less of an issue, because "Chrome-only" web developers will start to recognize & fix this issue when they test there.
Comment 15•7 years ago
|
||
> the Chrome developers are trying to change Chrome to match the spec
That's great news. "Chrome-only" developers will notice the breakage and will have to move to a standards-conform encoding. While I don't neccesary agree with the required escaping (it seems unituitive to require escaping of UTF-8 content, but I guess that is the legacy burden of Data URIs being URIs after all).
You need to log in
before you can comment on or make changes to this bug.
Description
•