Closed Bug 826562 Opened 11 years ago Closed 11 years ago

SVG Data URL with a "#" character ends up broken (since # is treated as end of start of #reference)

Categories

(Core :: SVG, defect)

17 Branch
x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: gottfried.haider, Unassigned)

References

Details

(Whiteboard: [webcompat])

Attachments

(1 file)

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.
Attachment #697743 - Attachment mime type: text/plain → text/html
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: 11 years ago
Resolution: --- → INVALID
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)
>to the whatwgmake 
er "to the whatwg, to make"
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
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
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
No problem!
(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
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)
Flags: webcompat?
Whiteboard: [webcompat]
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
Better fiddle highlighting the issue: https://jsfiddle.net/zoyam19h/3/
@silverwind updated your last fiddle to include Opera https://jsfiddle.net/zoyam19h/6/

Is Firefox slowly turning into the poorer cousin?
(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.
> 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.

Attachment

General

Created:
Updated:
Size: