Intent to Deprecate and Remove: Support for '#' in data URI body

[smcg...@chromium.org]

Primary eng (and PM) emails

smcg...@chromium.org

Summary

Chromium currently allows '#" symbols to exist in the body of a data URI,
in violation of the URL spec. More specifically, it treats a '#' as *both*
part of the data body and the start of the URL fragment, such that there is
an overlap between the two components.

We intend to align properly to the spec (and Firefox) by treating the
first '#' of a data URL as the end of the data body and the start of the
fragment.

Motivation

   - Consistency with spec.
   - Websites that include a '#' in data URIs will operate differently in
   different browsers.
   - Makes it possible to use fragments in data URIs properly in Chromium.

Interoperability and Compatibility Risk


Edge: Same behavior as Chromium; does not properly handle '#' in data URIs.
Firefox: Properly handles '#' in data URIs.
Safari: Same behavior as Chromium; does not properly handle '#' in data URIs. There is an old bug discussing changing with mixed signals, but it predates recent efforts to make the URL spec clearer. https://bugs.webkit.org/show_bug.cgi?id=68089

Alternative implementation suggestion for web developers

'#' symbols in data URIs must be encoded as '%23', e.g.:

background-image: url(data:image/svg+xml,<svg xmlns="..."><path fill='#FFF'...);

Should be replaced by:

background-image: url(data:image/svg+xml,<svg xmlns="..."><path fill='%23FFF' ...);

Usage information from UseCounter
https://www.chromestatus.com/metrics/feature/timeline/popularity/2216


The current usage is high (~0.5%), but based on UKM data, the feature usage
is largely from Google properties, and non-Google properties do not make up
a significant portion. We have open bugs with the relevant team to fix
their incorrect usage of '#' in data URIs.

OWP launch tracking bug
crbug.com/123004

Entry on the feature dashboard
https://www.chromestatus.com/feature/5656049583390720

Requesting approval to remove too?
 Intent to Deprecate and Remove: Support for '#' in data URI body
Yes; plan is to remove in M67. We are considering a deprecation plan for
M66 - it may be possible to add a console warning when data URIs with '#'
symbols are used *but* this will have false positives.

[Rick Byers]

LGTM1 to give this removal a shot based on the argument that it's almost exclusively Google properties impacted and you're proactively working to address those, and that any breakage will often represent existing Firefox breakage (or need for special casing). Of course we may need to revert if we find significant breakage and need some more time.

Given that anecdotally the cases you've identified in Google code have all being real issues (nobody really seems to want a fragment identifier in a data URL), then I'd suggest going with the deprecation message for one milestone (maybe even leave a warning in place for a milestone afterwards?).  Our rule of thumb is generally to warn when we expect <50% false positives.

It's worth noting that this issue has been seen in real Firefox/Chrome compat issues.  Also I enjoyed the anecdote around reaching out to Facebook.  IIRC they had at one point noticed things were broken on Firefox but didn't understand why and so had a UserAgent-string specific hack to base64-encode data URLs for Firefox.  Thanks to your outreach they were able to eliminate both the inefficiency of base64 encoding and the need to do any sort of UA check by simply escaping the octothorpe.  Eliminating future potential for that sort of confusion/pain is exactly why it's worth taking some compat pain to fix bugs like this (think of all the developers who could have hit this and suffered in silence, or not-silence).  Thanks for pushing on it!

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/250416b3-fb7e-413b-834c-354554a0694f%40chromium.org.

[Philip Jägenstedt]

LGTM2

Since this is a real compat issue, it's important that we find a way to interop, and this seems like the best first thing to try. If that should fail, then our current behavior is really quite weird, but maybe we could find a way. Let's hope the first path works out instead.

I will also be looking for opportunities to use the word octothorpe :)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_pF2KT62cXBkm3YTHv-vsiA77wi%3DxGwXRyhv9-M29SPg%40mail.gmail.com.

[Chris Harrelson]

LGTM3 for M67 plan. Hopefully it's possible to add a console warning.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYcYLZE64QCYAXd-prb1jTFewhsRDJw4XG23qtJSa9n4_Q%40mail.gmail.com.

[smcg...@chromium.org]

Wanted to give an update on this since it has been some time and - as the eagle-eye observer might note - we haven't landed the removal.

Unfortunately usage of this feature was higher than expected on Android WebView, at the level where an immediate deprecation would break too many WebView pages. We are currently working with the WebView team to identify a way to give them a longer deprecation period, but unfortunately the code change required to fix the data URI issue is outside of third_party/blink (where most of the existing WebView quirks are implemented). I do not expect deprecation of this feature to happen until at least M69.

Note that usage is also still quite high on non-WebView Chrome (https://www.chromestatus.com/metrics/feature/timeline/popularity/2216). I am continuing outreach to the larger sites that I have been able to identify, and have received positive responses so far.

[David Benjamin]

I was mostly watching on the sidelines, but I remember a lot of the initial failures was in the WebView.loadData API (and friends). Is it primarily that, or is there also a lot of it embedded in the web(view) content itself?

If it's only those APIs, you could imagine just saying loadData replaces "#" with "%23" and we just declare it's not worth caring about that. data URLs evaluated inside the rendering engine proper would still inherit the spec-compliant behavior. (That API is kind of goofy anyway. Rather than taking a URL or raw data, it takes a partially assembled data URL. Deprecating it with a weird quirk in favor of a new API that takes raw unencoded data seems not the end of the world.)

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYcYLZE64QCYAXd-prb1jTFewhsRDJw4XG23qtJSa9n4_Q%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/600b9011-1384-467c-92f6-0d81c204591d%40chromium.org.

[Philip Jägenstedt]

That is a shame, but thanks for the update Stephen. I really hope it still works out one way or another, because the alternative would be something quite odd :)

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Stephen Mcgruer]

Circling back to this (so long ago!): as of M73 reaching stable we have now survived a full release (M72) with this deprecation in place, and successfully dealt with a P1 WebView issue relating to it (crbug.com/929083, https://chromium-review.googlesource.com/c/chromium/src/+/1456638). The deprecation has landed :).

[Ojan Vafai]

Nice! Thanks for the hard work getting us an incrementally more cross browser web. 

Stephen Mcgruer wrote:

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3Mad%3DLyCWLzBFegCdyKKhem%3DoDckKKZkLqSKr_9W6hCw7Vg%40mail.gmail.com.

[Philip Jägenstedt]

Thank you indeed, Stephen! The original plan was to remove in M67, what is the new plan for removal now? (I looked in deprecation.cc but failed to guess the name of the counter. It's not https://www.chromestatus.com/metrics/feature/timeline/popularity/2216 it seems.)

[Stephen Mcgruer]

Oh sorry Philip, my email was unclear. The deprecation was already in place from M67 onwards. The *removal* landed in M72 and has survived a release cycle. That's why I'm so excited :)

[Philip Jägenstedt]

Oh, WOW, that is much more exciting! Thank you for getting this all the way across the finishing line!