1367965 - data URL and hash sign in CSS background-image using SVG

Status: RESOLVED WORKSFORME

(Core :: Networking, enhancement, P3)

Description

[Karl Dubost💡 :karlcow]

This is a followup on Bug 658949 where we fixed the hash in data URL

As of today, with 
  data:text/html,<h1 id="a">AA</h1>#a

* Firefox Nightly 55.0a1 (2017-05-24) (64-bit) 
  Content = "AA"
* Safari  Release 30 (Safari 10.2, WebKit 12604.1.22)
  Content = "AA #a"
* Opera 46.0.2597.6 (Chrome/59.0.3071.26)
  Content = "AA #a"


I'm opening a separate bug because of a regular pattern we have seen on some issues. 

https://webcompat.com/issues/5906
.fbShare span {
    background-image: url('data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 16" class="_1pbq"><path fill="#ffffff" fill-rule="evenodd" d="M8 14H3.667C2.733 13.9 2 13.167 2 12.233V3.667A1.65 1.65 0 0 1 3.667 2h8.666A1.65 1.65 0 0 1 14 3.667v8.566c0 .934-.733 1.667-1.667 1.767H10v-3.967h1.3l.7-2.066h-2V6.933c0-.466.167-.9.867-.9H12v-1.8c.033 0-.933-.266-1.533-.266-1.267 0-2.434.7-2.467 2.133v1.867H6v2.066h2V14z"></path></svg>');
}

https://webcompat.com/issues/6523
.ls-jupiter .ls-nav-prev {
	background-image: url('data:image/svg+xml; utf8, <svg xmlns="http://www.w3.org/2000/svg" width="11.43" height="16" class="mk-svg-icon" style="fill:#fff;" viewBox="0 0 1280 1792"><path d="M1171 301l-531 531 531 531q19 19 19 45t-19 45l-166 166q-19 19-45 19t-45-19l-742-742q-19-19-19-45t19-45l742-742q19-19 45-19t45 19l166 166q19 19 19 45t-19 45z"></path></svg>');
}


https://webcompat.com/issues/6063
.i--long-arrow-right {
	background-image: url("data:image/svg+xml;charset=utf8,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20width='58'%20height='36'%20viewBox='0%200%2058%2036'%3E%3Cpath%20fill='#fff'%20d='M52.2%2016.9l-14.1-13.8%201.9-1.7%2016.6%2016.5-16.6%2016.7-1.8-1.8%2014.1-13.7h-51.3v-2.2h51.2z'/%3E%3C/svg%3E");
}

Comment 1

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 2

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 3

[Thomas Wisniewski]

It now appears that Blink intends to match the spec as Firefox does, as their UKM data shows it is mostly Google properties relying on the non-spec behavior: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/_g_HnAHkMPo/1DrejG5mAgAJ

If that intent goes through, we should be able to close this bug.

Comment 4

[Mike Taylor [:miketaylr]]

Update from May 15, 2018

> 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.

Comment 5

[Firefox Bug Husbandry Bot]

See bug 1547409. Migrating webcompat priority whiteboard tags to project flags.

Comment 6

[Karl Dubost💡 :karlcow]

Attachment: firefox top, chrome middle, safari bottom

For this specific test.

  data:text/html,<h1 id="a">AA</h1>#a

• Blink and Gecko are aligned now
• Webkit is the outlier

Tested on Desktop in

• Firefox Nightly 82.0a1 (2020-08-31) (64-bit)
• Chrome Canary Version 87.0.4250.0 (Build officiel) canary (x86_64)
• Safari Tech Preview Release 112 (Safari 14.0, WebKit 15610.1.25.5.1)

Comment 7

[Karl Dubost💡 :karlcow]

Attachment: GitHub Pull Request

https://bugs.webkit.org/show_bug.cgi?id=68089#c33

FYI (without any comment on what anyone should or shouldn't do!): Blink's (second) attempt at removing this landed in our M72 milestone, and has now survived an entire milestone in the field (as M73 has started rolling out). Chromium is now aligned with the spec and Firefox; '#' in data URIs mark the end of the content and the start of the fragment.

This landed in Chrome in 2019. And it now follows both the spec and Firefox.
https://bugs.chromium.org/p/chromium/issues/detail?id=929083

We can close this bug.

And the web platform already exists