New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 123004 link

Starred by 31 users

Issue metadata

Status: Started
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , iOS , Chrome , Mac , Fuchsia
Pri: 2
Type: Bug

Blocked on:
issue 823666



Sign in to add a comment

incorrect handling of fragment identifiers in data: URIs

Reported by julian.r...@gmail.com, Apr 11 2012

Issue description

Chrome Version       : 18.0.1025.152 m
URLs (if applicable) : http://greenbytes.de/tech/tc/datauri/#simplewfrag
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 5: FAIL
  Firefox 11: OK
       IE 7/8/9: not supported

What steps will reproduce the problem?
See test case: in 

  data:,test#foo

"#foo" is the fragment identifier; it should not be treated as part of the content.

What is the expected result?
A text/plain resource with content "test"

What happens instead?
A text/plain resource with content "test#foo"

Please provide any additional information below. Attach a screenshot if
possible.

See aso RFC 3986 and RFC 2397.
 
Showing comments 3 - 102 of 102 Older
> Firefox and Opera appear to strip the #foo from the content of the document.

Opera: matches Safari/Chrome.

Firefox apparently applies a conforming URI parser, and thus does not consider the #foo as part of the content.

> IE doesn't support creating documents from data URLs, so it's hard to test how it interprets these URLs.

I think it might for other content types; so I'll need more tests.

PS: the point I was trying to make was that Firefox has been doing what the spec says for some time now and it doesn't appear to cause problems.
See also

  http://greenbytes.de/tech/tc/datauri/#svg

...so for the media types where IE supports data URIs, it behaves like Firefox, treating the fragment identifier correctly.

Comment 5 by brettw@chromium.org, Apr 13 2012

This is a known limitation. I'm sure there is another bug for this, but I can't find it.

We should change our behavior, but the change is quite challenging because of existing assumptions in the code, and has very little real-world impact. I was going to say that this is the first real page I've seen the bug affect, but it's actually a test also. This affects some of our layout tests.
Project Member

Comment 6 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-Internals Cr-Internals

Comment 7 by math...@qiwi.be, Jul 25 2013

Opera 12 supported this, but Opera 15 (with Blink/Chromium) no longer does. This is a regression.

Comment 8 by jrmui...@gmail.com, Jul 26 2013

See also  issue 259514  and the url specification http://url.spec.whatwg.org/
 Issue 259514  has been merged into this issue.

Comment 10 Deleted

Note that # is *not valid* as part of the data-part of a data URI so what Chrome is doing violates the spec. It would need to be %23 to be included as part of the data, as per the RFC.

Comment 12 by bolde...@gmail.com, Nov 29 2013

The problem also extends to the QUERY part of the URI. See especially

http://lists.w3.org/Archives/Public/uri/2013Jul/0003.html

with the link to the RFC2397 errata. I've put together a small test here, using Blob URLs:

http://jsfiddle.net/boldewyn/vLNvA/

About the *little real-world impact*: I want to contradict here. There are many use-cases, that cannot be followed right now because of *this very* bug. As I showed above, Blob URLs and data: URI have the same problem in Chrome. You don't need much phantasy to find interesting applications. Off the top of my head: "Dynamically create SVG in the browser, like SVGEdit. Then add several views, determined by ID. Let the user preview the views by creating a Blob URL with the query part set.", "Dynamically add SVG filters via CSS filter property as data URIs, linking to the <filter> element inside.", "Markdown editor: show preview dynamically and hop to currently edited section of longer text"...

This bug lies at the very core of one pillar of the web: URI handling. You should treat it as such.
 Issue 324251  has been merged into this issue.

Comment 14 by rob@robwu.nl, Mar 28 2014

This unusual treatment of "#" in data-URIs has several disadvantages:

- base64-encoded data-URIs are non-functional when there's a # character. E.g. data:text/html;base64,# results in "The webpage is not available".

- Anchors in data-URIs break the data URI. E.g. visit
data:text/html,<a href="#x">link</a>, then click on the link. Everything after the first "#" is truncated and replaced with the new reference fragment in the omnibox:
data:text/html,<a href="#x
If you then press F5, then the content is significantly different.

- Content where "#" is significant, e.g. "#t=30,60" for audio, #anelement for SVG cannot use the features of "#".

- Data URIs can easily hide undetectable content:
  data:text/html,#<script>location.hash = '#';alert('spoofed');</script>
  data:text/html,# (after loading the previous URL)

- Chromium extensions that redirect to data-URIs have no control over the fragment, unless they append a "#". to the URI ( issue 354653 ).


One useful argument for the current behavior is that it's easier to hand-write content that contains "#", e.g. data:text/html,<span style="color:#F00">red text</span>. This feature does not outweigh the disadvantages, IMO.


Comment 15 by bolde...@gmail.com, Mar 31 2014

data: URIs are still URIs, so they can be URL-encoded just fine. The "#" inside the data: URI's payload can (and should) be written as "%23" and serves its purpose in the content like specified. (Just like "%" must be encoded, else be interpreted as escape sequence.)
Owner: e...@opera.com
Status: Assigned
Adam: Would you mind if Erik takes this? https://codereview.chromium.org/338503006/
Labels: -Cr-Internals Cr-Internals-Network
Cc: asanka@chromium.org

Comment 19 by e...@opera.com, Jun 17 2014

Blocking: chromium:120248

Comment 20 by e...@opera.com, Jun 17 2014

Regarding comment #12:
If we take the errata #2045 for RFC2397, see http://www.rfc-editor.org/errata_search.php?rfc=2397, then the QUERY part is still part of the data URL unless it's escaped. Is that the intent?

From RFC2396:
uric = reserved | unreserved | escaped
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | ","

The data of a data URL is "scheme data", followed by "?" if query is non-empty, followed by query. Fragment is not part of it. (But is used for processing.)

Comment 22 by e...@opera.com, Jun 18 2014

Thanks Anne,
will compare notes with the URL spec too.

Spec reference: http://url.spec.whatwg.org/#parsing
It's pretty simple. Just parse the data URI like any other URI. See also <http://greenbytes.de/tech/tc/datauri/#svg>.
The old bug is probably  issue 291747  which is fixed (need to parse the scheme in the first place). So I think this bug is just that the data url parsers don't know about this, in which case something along Erik's fix above would be what's required.

(I didn't do a lot of thinking about what the right behavior is, so don't treat this as an endorsement for any particular approach.)

Comment 25 by e...@opera.com, Jun 19 2014

Webkit bug for the same issue: https://bugs.webkit.org/show_bug.cgi?id=68089
Which web sites will be fixed by this change and which web sites will be broken?  I'm worried that the number of web sites broken will outnumber the number fixed by a large margin, especially on the mobile web.
Looks like the WebKit bug is: https://bugs.webkit.org/show_bug.cgi?id=68089 - please read that for context.


Sorry for the spam - didn't see that ed just posted that bug link a few hours ago. I'm going to ping the WebKit bug just to see if anyone there has any thoughts.

Comment 29 by e...@opera.com, Jan 9 2015

Cc: ashej...@chromium.org
 Issue 447119  has been merged into this issue.

Comment 30 by e...@opera.com, May 6 2015

Owner: ----
Status: Available
 Issue 492268  has been merged into this issue.
Could someone verify if Chrome would parse the fragment identifier if using the filesystem or blob uri scheme? For example using URL.createObjectURL(blob) or fileEntry.toURL()

Comment 33 by rob@robwu.nl, Sep 11 2015

#32
Paste the following snippet in the console, and visit the result in a new tab.
URL.createObjectURL(new Blob(['<div id=top style="height:100vh">.</div><a id=bottom>bottom</a><a href=#top>Go to top</a><div style="height:100vh">.</div>'],{type:'text/html'})) + '#bottom'

When I navigate to the given URL, the document jumps to the #bottom anchor.
When I click on the "Go to top" link (#top), the page jumps to the top.

So fragment identifiers work as intended for blob:-URLs.
Cc: rocalla...@mozilla.com
Labels: Hotlist-Interop
rocallahan@ from Mozilla tells me this poses real interop pain in practice.  Rob can you elaborate on the concrete use cases you've seen affected (especially any real sites that behave differently in different browsers, or need UA-specific code as a result)? 
I don't have any data on real sites behaving differently. I do have examples of people being confused by the lack of interop and reporting it as a Firefox bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=826562
https://bugzilla.mozilla.org/show_bug.cgi?id=937993
You can see examples of such confusion in this bug too. So while it may not be reaching real sites, it does seem to cause problems for authors. Feel free to prioritize it below problems that are reaching real sites (like the canplaythrough bug).

The old WHATWG thread on this is here: https://lists.w3.org/Archives/Public/public-whatwg-archive/2011Sep/0100.html. It converged on the consensus to treat # strictly per RFC.

Comment 36 by rob@robwu.nl, Sep 23 2015

@Rick, I've already listed the potential issues at https://code.google.com/p/chromium/issues/detail?id=123004#c14.

Firefox's way of treating data-URLs (=like a normal URL) is the most sensible one in my opinion, and I believe that we should converge in that direction.

Comment 37 by creis@chromium.org, Nov 25 2015

Cc: japhet@chromium.org creis@chromium.org
 Issue 528454  has been merged into this issue.
Blocking: -120248
Project Member

Comment 39 by sheriffbot@chromium.org, May 4 2017

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been available for more than 365 days, and should be re-evaluated. Please re-triage this issue.
The Hotlist-Recharge-Cold label is applied for tracking purposes, and should not be removed after re-triaging the issue.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Status: Archived (was: Untriaged)
Network bug triager here.  No real activity on this in years, was available but never picked up.  I'm going to archive. 
Status: Available (was: Archived)
This is a case where browsers behave differently, which is a bug on one end or the other. I think we should leave it open, even though, yeah, it doesn't appear anyone has gotten to it.
Thank you for keeping it open.
Cc: -abarth@chromium.org rbyers@chromium.org
Status: Untriaged (was: Available)
https://bugzilla.mozilla.org/show_bug.cgi?id=1377282 discusses a case where there is a real-world interop problem due to this.  

One repro: http://todomvc.com/examples/polymer/index.html
Add an item to the list and look at the checkbox.
Chrome gets a custom-styled checkbox but standards-conformant browsers like Firefox do not.

This is because of CSS like the following:

.todo-list li .toggle:checked:after {
    content: url('data:image/svg+xml;utf8,<svg xmlns="http://www.w3.org/2000/svg" width="40" height="40" viewBox="-10 -18 100 135"><circle cx="50" cy="50" r="50" fill="none" stroke="#bddad5" stroke-width="3"/><path fill="#5dc2af" d="M72 25L42 71 27 56l-4 4 20 20 34-52z"/></svg>');
}

Given that this is happening in THE canonical web sample application, it seems likely that developers are copying this pattern in other places and being confused by the lack of interop.  So I'd consider this to be pretty darn "real-world" (even though it's a sample not a production site).

If there's further question on the lack of impact, perhaps we should add a UseCounter that triggers in this case to get a measure?  We could consult the HTTP Archive top 500k to find all sites there that trigger the counter (if there are less than a few then I'd consider that stronger evidence that this is correctly low priority).

But if there is some usage and the consensus is that the currently specified behavior is really the right one, then we really should try to change Chrome to match to avoid people thinking such things can work.

Back to network triage queue.  Can someone familiar with this code indicate how hard this is likely to be to fix?  Could we at least get closer to the standardized behavior by naively stripping everything after a # or ? off of the URL?
Cc: mkwst@chromium.org
I would imagine (but don't actually have any clue) that all the code is in //url somewhere and would be, code-wise, easy enough to fix. Breakage-wise, I have even less clue. Us net folks don't own //url or venture out into web platform land very often, so we're probably not the right people to ask. :-)

brettw, mkwst (url/OWNERS): Thoughts?
Components: -Internals>Network Blink>Loader
I don't think this is an issue in //url. GURL parses `data:` URLs such that the following tests pass:

```
GURL url("data:text/html,Question?<div style=\"color: #bad\">idea</div>");                                                      
EXPECT_EQ("data", url.scheme());
EXPECT_EQ("text/html,Question", url.path());
EXPECT_EQ("<div style=\"color: ", url.query());
EXPECT_EQ("bad\">idea</div>", url.ref());
```

and

```
KURL url(kParsedURLString, "data:text/html,Question?<div style=\"color: #bad\">idea</div>");
EXPECT_EQ("data", url.Protocol());
EXPECT_EQ("text/html,Question", url.GetPath());                                                                                 
EXPECT_EQ("<div style=\"color: ", url.Query());
EXPECT_EQ("bad\">idea</div>", url.FragmentIdentifier());
```

This is more likely to be an issue in Blink's resource loading code's handling of `data:` URLs. Shifting components accordingly.
gurl.h says "Data and javascript URLs use GetContent() to extract the data". That's probably where it's coming from.
Cc: kouhei@chromium.org
Great!  If it's possible to fix this in blink without changing GURL that should make it easier/safer.  There's some compat risk here, but given that Firefox already has the spec-conformant behavior I think we should just try and see.  If we hit non-trivial breakage than we have a strong argument for changing the spec.

kouhei@ WDYT?
Components: Internals>Network
Hrm. Although gurl.h says to use GetContent(), it's not clear to me anything is doing that. Actually I was wrong about //net not being involved. If a data URL reaches the net stack's URLRequestDataJob, we hit net::DataURL::Parse which apparently just reparses the string from scratch (merp), rather than use GetContent() as documented.
https://cs.chromium.org/chromium/src/net/base/data_url.cc?type=cs&l=23
(Re-adding Internals>Network to capture the //net half of this.)

But GetContent() does not do the right thing either. It queries Length() here:
https://cs.chromium.org/chromium/src/url/third_party/mozilla/url_parse.cc?rcl=2e4131386bba37ceb1201e46f0e2834390f93e0f&l=802
Which includes the ref if there is one:
https://cs.chromium.org/chromium/src/url/third_party/mozilla/url_parse.cc?l=733
(Note GetContent() is shared with some other stuff.)

That said, I would also expect Blink processes some data URLs itself rather than round-trip to the renderer just to do a base64-decode of stuff it already has. So net::DataURL may not the only place to fix this. (Keeping Blink>Loader accordingly.) Blink folks, do you know of other bits we'd need to fix this?
> #48
> Blink processes some data URLs itself
Blink's ResourceFetcher creates the response of Data URLs by itself, but ResourceFetcher also uses net::DataURL::Parse() (via NetworkUtils::ParseDataURLAndPopulateResponse()), so I expect fixing net::DataURL::Parse() is sufficient.

Perfect! (I suppose I could have just checked if you all call that function.)

Also, more reasons to fix this: we actually behave rather absurdly right now. If you load:

 data:text/html,<div style="height:2000px"></div><a id="foo">bar</a>#foo

we both interpret #foo as URL contents AND jump to the bottom of the page. Also if you then change #foo to #fooo, we treat that as having changed only the ref and just scroll somewhere, even though net::DataURL would have parsed it differently.

So I guess the only question is what to do about GURL::GetContent. mkwst?

I can imagine a few options here:

1. Make GURL::GetContent() strip off the URL ref. This matches all the comments saying it's suitable for data: URLs, but it might break existing callers. It also seems to be wrong for javascript: URLs. Both Chrome and Firefox parse javascript:alert("#") as alert("#").

2. Introduce a new GURL::GetContentWithoutRef() and fix all the comments to say data: URLs should use this one. (Blob URLs too I imagine?) Maybe at some point rename GetContentWithoutRef => GetContent, GetContent => GetContentWithRef. It seems most of the time you don't want the ref in there, to avoid double-interpreting it.

3. net::DataURL just manually stops at # itself.

I tried to find the formulation in the spec, but WHATWG seem to be about as confused as we are. The closest thing this is to being specified is a citation here:
https://fetch.spec.whatwg.org/#concept-scheme-fetch
However, that citation just goes here which is less a specification and more a list of grievances.
https://simonsapin.github.io/data-urls/
I'm guessing the Fetch text was written before this change:
https://github.com/SimonSapin/data-urls/commit/82fe8eb2b72c9d9dba6b936c5237a24aa3dc2726

I don't like (3). It seems we shouldn't be parsing parts of a URL twice. That net::DataURL is manually looking for the ':' right now seems wrong. Although it is the easiest option, I suppose. I'm thinking (2), probably with the rename, makes the most sense?


As far as moving forward, I probably do not have time to drive all the Blink process and measurement business (I'm a crypto and TLS person...). So if "try and see" per comment #47 is indeed sufficient Blink-wise and //url OWNERS say which of 1-3 they prefer, I can take this for the sake of unblocking it. But if not, someone other than me should be driving it.
#50 - yeah, a pretty wacky and inconsistent behavior, reported as  issue 528454  (merged into this one).
I'd be fine with splitting `GetContent` into versions with and without the hash bit. That sounds like the option most likely to solve the specific problem we're dealing with here.


Given the existing weirdness in our behavior, I think I agree with Rick that we can try this change and see what happens; if you'd like to take a stab at it, davidben@, perhaps we could also add a counter inside ResourceFetcher to see how often we end up with a fragment on a data URL?
(loader-side triager here) having a GetContext version for ref-stripping and use it for data URL cases sgtm/2, and yes if someone can take a stab in net::DataURL we can certainly make the counter change in Blink side.
Labels: M-62
Owner: davidben@chromium.org
Status: Assigned (was: Untriaged)
Alright, I can take care of the code side of things here, though branch is soon, so I'll time this to land south of 61 branching.
Cc: mea...@chromium.org phistuck@chromium.org brajkumar@chromium.org
 Issue 749885  has been merged into this issue.
Cc: davidben@chromium.org
Owner: smcgruer@chromium.org
My understanding from davidben@ is that he does not currently have the bandwidth to land any fix here himself (thanks for taking it 90% of the way David!).

I have two exploratory CLs up atm to add GetContentWithoutRef (https://chromium-review.googlesource.com/c/chromium/src/+/738395) and make net::DataURL::Parse use it (https://chromium-review.googlesource.com/c/chromium/src/+/737553) which I am happy to own and see through commit.

What I don't have the expertise in is what checks or counters we should add to measure the breakage mentioned in #47, or how to add them.

If someone on this bug can help with that part, I would very much appreciate it.
After chatting with Rick, he suggested both trying a HTTP Archive query to see if we could find data URI requests with '#' symbols, and landing a UseCounter to count them.

So far, I'm starting to believe I either don't understand BigQuery, or the HTTP archive ignores data requests:

(https://bigquery.cloud.google.com/savedquery/451690379072:647422111dc1492b9b09f095908142b2)
SELECT * FROM [httparchive:har.latest_requests_desktop]
WHERE REGEXP_MATCH(url, '^data');

> Query returned zero records.
Cc: -ashej...@chromium.org
Project Member

Comment 59 by bugdroid1@chromium.org, Nov 2 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2005954f597aaeb810f03f1b4d5f221c99c20f4d

commit 2005954f597aaeb810f03f1b4d5f221c99c20f4d
Author: Stephen McGruer <smcgruer@chromium.org>
Date: Thu Nov 02 12:44:10 2017

Add UseCounter to track use of octothorpes ('#') in data URIs

Chrome currently violates the URI spec by treating '#' characters in
data URIs as both part of the data body and also as the start of the URI
ref section. By the URI spec a '#' character immediately stops the data
body and indicates the start of the URI ref section.

Ahead of trying to align Chrome to the spec, we should attempt to
measure how often developers are trying to use data URIs with '#'
characters in them. This UseCounter attempts to do this, but is not
perfect measure. It will count spec-compliant usecases and will miss
cases that don't use FrameFetchContext to do their resource fetching.

Bug: 123004
Change-Id: I4babf89912d738c0c63affa56e39cd8a53933c38
Reviewed-on: https://chromium-review.googlesource.com/748806
Reviewed-by: Charlie Harrison <csharrison@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Commit-Queue: Stephen McGruer <smcgruer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#513468}
[modify] https://crrev.com/2005954f597aaeb810f03f1b4d5f221c99c20f4d/third_party/WebKit/Source/core/loader/FrameFetchContext.cpp
[modify] https://crrev.com/2005954f597aaeb810f03f1b4d5f221c99c20f4d/third_party/WebKit/Source/core/loader/FrameFetchContext.h
[modify] https://crrev.com/2005954f597aaeb810f03f1b4d5f221c99c20f4d/third_party/WebKit/Source/platform/loader/fetch/FetchContext.h
[modify] https://crrev.com/2005954f597aaeb810f03f1b4d5f221c99c20f4d/third_party/WebKit/Source/platform/loader/fetch/ResourceFetcher.cpp
[modify] https://crrev.com/2005954f597aaeb810f03f1b4d5f221c99c20f4d/third_party/WebKit/public/platform/web_feature.mojom
[modify] https://crrev.com/2005954f597aaeb810f03f1b4d5f221c99c20f4d/tools/metrics/histograms/enums.xml

smcgruer: To the extent that we are looking at data URI issues, could we also count instances of unescaped non-urlchars and query strings?
asanka: Can you point me at the part of the spec that violates, or give some examples as to what is good/bad? I'm not very familiar with this area.
Cc: -phistuck@chromium.org
For HTTP Archive I was suggesting just a naive grep, eg maybe something naive like:

SELECT page, url
FROM [httparchive:har.2017_10_01_chrome_requests_bodies]
REGEXP_MATCH(body, r'[^a-zA-Z0-9]data:[a-zA-Z0-9:,_;=]#'

See https://docs.google.com/document/d/1cpjWFoXBiuFYI4zb9I7wHs7uYZ0ntbOgLwH-mgqXdEM/edit# for some other examples.

But UseCounters are the gold standard - if a UseCounter is relatively low, then that's likely sufficient to ship this change.  If it's not so low then more analysis (eg. via HTTP Archive) of the risk may be needed.
kDataUriHasOctothorpe has started to roll out on dev Chrome, and the results are certainly interesting; around 2% of page views have data URIs with '#' in them! https://www.chromestatus.com/metrics/feature/timeline/popularity/2216

I took a stab in the dark and checked both Gmail and Facebook. Gmail is clean, but Facebook indeed uses such URIs for their CSS <link>s... on Chrome only.

Yep, on Chrome Facebooks has HTML such as:

<link ... href="data:text/css; charset=utf-8,#bootloader_P_mr5{height:42px;}.bootloader_P_mr5{display:block!important;}" ... >

On Firefox, it looks like:

<link ... href="data:text/css; charset=utf-8;base64,I2Jvb3Rsb2FkZXJfUF9tcjV7aGVpZ2h0OjQycHg7fS5ib290bG9hZGVyX1BfbXI1e2Rpc3BsYXk6YmxvY2shaW1wb3J0YW50O30=" ... >

I'm going to continue poking around other high traffic sites and seeing if I can manually trigger the UseCounter.
Note: across alexa top 10, Facebook is the only site I can find that triggers the use counter.
That base64 blob decodes to:

  #bootloader_P_mr5{height:42px;}.bootloader_P_mr5{display:block!important;}

which suggests what happened was Facebook originally wrote the Chrome URL, noticed it didn't work in Firefox, and base64-encoded it rather than realizing they should be hex-encode # as %23! That I believe will work in each of Chrome-today-with-bug, Firefox, and Chrome-tomorrow-with-bug-fixed.

Blink folks, could we point some Facebook contacts here so they can fix that? I'll poke my contacts, but since I mostly do TLS stuff, I don't know how close they are to their JavaScript serving bits like this.
Labels: DevRel-Facebook
We have confirmation from Facebook that they are aware of this bug and will discuss after the Thanksgiving break and give an ETA for a fix on their side.

Comment 69 by rbyers@google.com, Dec 4 2017

Looks like usage has now fallen to 0.4%.  A lot lower, but still high enough to worry about.  Maybe a good candidate for UKM (talk to loonybear)
Cc: loonyb...@chromium.org
Yea the usage is > 0.1% so it is too high to change blindly. I will add this feature to UKM for you.
Project Member

Comment 71 by bugdroid1@chromium.org, Dec 6 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6afdb0f673d29fc37f6b860ccd68c4de3ed74087

commit 6afdb0f673d29fc37f6b860ccd68c4de3ed74087
Author: Luna Lu <loonybear@chromium.org>
Date: Wed Dec 06 15:37:58 2017

Opt in features to UKM UseCounter

1. Vibrate features:
Nav / safe browing team  would like to collect URLs where vibrate is used when:
 a. from the top frame or iframe (ads);
 b. vibrate with user gestures.
2. Touch events:
 understanding reasons where scrolling is prevented without using touch-action.

Features listed above all have shown <1% of page views from chromestatus.com and satisfy UKM privacy constraints.

Bug: 706389, 123004
Change-Id: I3d2d48e1e7703d2cc4c05c35b7d4ba6d613d1ca7
Reviewed-on: https://chromium-review.googlesource.com/801754
Commit-Queue: Luna Lu <loonybear@chromium.org>
Reviewed-by: Bryan McQuade <bmcquade@chromium.org>
Cr-Commit-Position: refs/heads/master@{#522094}
[modify] https://crrev.com/6afdb0f673d29fc37f6b860ccd68c4de3ed74087/chrome/browser/page_load_metrics/observers/use_counter/ukm_features.cc
[modify] https://crrev.com/6afdb0f673d29fc37f6b860ccd68c4de3ed74087/chrome/browser/page_load_metrics/observers/use_counter_page_load_metrics_observer.h
[modify] https://crrev.com/6afdb0f673d29fc37f6b860ccd68c4de3ed74087/chrome/browser/page_load_metrics/observers/use_counter_page_load_metrics_observer_unittest.cc
[modify] https://crrev.com/6afdb0f673d29fc37f6b860ccd68c4de3ed74087/chrome/browser/page_load_metrics/page_load_metrics_browsertest.cc
[modify] https://crrev.com/6afdb0f673d29fc37f6b860ccd68c4de3ed74087/chrome/test/data/page_load_metrics/use_counter_features.html

Note: unfortunately the above CL was tagged with the wrong bug; loonybear@'s initial attempt to add kDataUriHasOctothorpe to UKM wasn't successful, so it was reverted. loonybear@'s plan is to root-cause why and land a specific patch adding the UseCounter for this bug.
We got the first set of data from UKM today (woo!), and the results are fairly conclusive - the top 25 entries are all Google domains (google.com, google.ca, google.co.uk, etc).

Unfortunately, there are a *lot* of products and a lot of code under google.com, so not yet sure where the actual usages are. I have found one so far:

https://www.google.ca/search?q=flowers&hl=en-CA&biw=412&bih=652&noj=1&tbs=vw:g,ss:44&tbm=shop&start=0&sa=N&srds=rp:1,rpsg:T5 (Android only; you should see a shopping results page with the filter sidebar already up.)

The outlines of the boxes (class sh-q__tick-outline) are masked using a data URL with an octothorpe in it:

url('data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 1 1" preserveAspectRatio="xMinYMin meet"><defs><clipPath id="a"><path d="M0 0v1h1V0H0zm.853.167L.96.273l-.53.53L.322.91.217.803.04.627.147.52l.176.177.53-.53z" fill="#fff"/></clipPath></defs><path clip-path="url(#a)" d="M0 0h1v1H0z"/></svg>)

To be correct, Google shopping should encode the '#' symbols as %23. I'm going to take a grok around their code and see if I can send them a patch, otherwise I'll do some outreach to the general team.
> To be correct, Google shopping should encode the '#' symbols as %23.

At the least, yes. But, the problem they have in general is that they're not percent-encoding *any* of the data for the data URI like they're supposed to. It should be like:

var dataurl = "data:image/svg+xml," + encodeURIComponent('<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 1 1" preserveAspectRatio="xMinYMin meet"><defs><clipPath id="a"><path d="M0 0v1h1V0H0zm.853.167L.96.273l-.53.53L.322.91.217.803.04.627.147.52l.176.177.53-.53z" fill="#fff"/></clipPath></defs><path clip-path="url(#a)" d="M0 0h1v1H0z"/></svg>');

(in JS terms in a UTF-8 page/context). As in, the content after the "data:image/svg+xml," in the URL is NOT raw SVG markup (in this case). It's percent-encoded data representing raw SVG markup that the browser needs to percent-decode to get the content when rendering/processing/handling.

I'm sure they do it (try to get away with not percent-encoding anything) to save bandwidth. But, if they're going to do that, they need to not break anything and chop off the URL content at a raw '#'.
Project Member

Comment 76 by bugdroid1@chromium.org, Jan 8 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/313d530f51c8ac8acffeb4c964ab75c1e870cd38

commit 313d530f51c8ac8acffeb4c964ab75c1e870cd38
Author: arthursonzogni <arthursonzogni@chromium.org>
Date: Mon Jan 08 09:35:22 2018

Add tests for data URLs with reference fragments.

If a data URL has a reference fragment, the '#' separator and the fragment
identifier should not be part of the data URL's data.

It can be very ambiguous, for instance in this URL:
data:text/html,<html><head><style type='text/css'>body
{color:#000000}</style></head><body>first</body></html>

The data is: "<html><head><style type='text/css'>body {color:"
The reference fragment is "#000000}</style></head><body>first</body></html>"

Bug:  793647 , 123004
Change-Id: I95183b607daedde4e0bbc8697c543fdd293e71d4
Reviewed-on: https://chromium-review.googlesource.com/822392
Reviewed-by: Camille Lamy <clamy@chromium.org>
Reviewed-by: Brett Wilson <brettw@chromium.org>
Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#527590}
[modify] https://crrev.com/313d530f51c8ac8acffeb4c964ab75c1e870cd38/content/browser/browser_side_navigation_browsertest.cc
[modify] https://crrev.com/313d530f51c8ac8acffeb4c964ab75c1e870cd38/content/browser/frame_host/navigation_controller_impl_browsertest.cc
[modify] https://crrev.com/313d530f51c8ac8acffeb4c964ab75c1e870cd38/url/gurl_unittest.cc

a) I'm very happy that this might finally get fixed. Almost six years!

b) The statement "It can be very ambiguos" is IMHO misleading - data URIs are URIs after all, and the syntax is described very clearly in RFC 3986 (obsoleting RFC 2396).

Comment 78 by bay...@gmail.com, Jan 8 2018

Re 77b: The ambiguity, of course, lies in the author's intent. 
Thanks for the investigation Stephen!  IMHO we shouldn't block interop on this just due to Google properties.  How much usage do you see via UKM for non-google properties?

As always, we should do our best to reach out to impacted sites and help them update - but it may be that the most efficient way to do this (and prioritize the work correctly) is to ship the change (then at least our bugs can say "... may be broken on current Chrome canary").  Feel free to send an intent to remove (breaking change request) - if the risk to non-google properties is minimal then I'd approve it (and worst case we can always revert before it hits stable to give more time for sites to update).
Status: Started (was: Assigned)
Intent to remove: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/_g_HnAHkMPo

It's worth noting there is some real compat risk here, but that's partly why it's worth the effort to do (shifts compat pain from spec-conformant to non-spec-conformant browsers).
Project Member

Comment 81 by bugdroid1@chromium.org, Jan 30 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/477a9c21852a80e1e2b54e2e6ca9b23012ffbce7

commit 477a9c21852a80e1e2b54e2e6ca9b23012ffbce7
Author: Stephen McGruer <smcgruer@chromium.org>
Date: Tue Jan 30 23:14:42 2018

Fix unescaped usage of '#' symbols in data URI bodies

These cases were discovered whilst adding a deprecation warning for the use of
'#' symbols in data URI bodies. For a '#' to exist inside the body, it must be
escape as '%23'.

Bug: 123004
Change-Id: If2e52db6c86d2610ecd0d4e175644494e18f47fc
Reviewed-on: https://chromium-review.googlesource.com/889718
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Rick Byers <rbyers@chromium.org>
Commit-Queue: Stephen McGruer <smcgruer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#533069}
[modify] https://crrev.com/477a9c21852a80e1e2b54e2e6ca9b23012ffbce7/third_party/WebKit/LayoutTests/fast/css-grid-layout/grid-item-display.html
[modify] https://crrev.com/477a9c21852a80e1e2b54e2e6ca9b23012ffbce7/third_party/WebKit/LayoutTests/fast/css/import-style-update.html
[modify] https://crrev.com/477a9c21852a80e1e2b54e2e6ca9b23012ffbce7/third_party/WebKit/LayoutTests/fast/css/link-disabled-attr.html
[modify] https://crrev.com/477a9c21852a80e1e2b54e2e6ca9b23012ffbce7/third_party/WebKit/LayoutTests/fast/css/stylesheet-parentStyleSheet.html
[modify] https://crrev.com/477a9c21852a80e1e2b54e2e6ca9b23012ffbce7/third_party/WebKit/LayoutTests/fast/dom/domListEnumeration.html
[modify] https://crrev.com/477a9c21852a80e1e2b54e2e6ca9b23012ffbce7/third_party/WebKit/LayoutTests/fast/dom/shadow/alternate-stylesheets.html
[modify] https://crrev.com/477a9c21852a80e1e2b54e2e6ca9b23012ffbce7/third_party/WebKit/LayoutTests/fast/loader/data-url-encoding-html.html
[modify] https://crrev.com/477a9c21852a80e1e2b54e2e6ca9b23012ffbce7/third_party/WebKit/LayoutTests/fast/loader/data-url-encoding-svg.html
[modify] https://crrev.com/477a9c21852a80e1e2b54e2e6ca9b23012ffbce7/third_party/WebKit/LayoutTests/fast/spatial-navigation/resources/iframe.html
[modify] https://crrev.com/477a9c21852a80e1e2b54e2e6ca9b23012ffbce7/third_party/WebKit/LayoutTests/fast/spatial-navigation/snav-iframe-with-outside-focusable-element.html
[modify] https://crrev.com/477a9c21852a80e1e2b54e2e6ca9b23012ffbce7/third_party/WebKit/LayoutTests/html/document_metadata/link-rel-stylesheet.html
[modify] https://crrev.com/477a9c21852a80e1e2b54e2e6ca9b23012ffbce7/third_party/WebKit/LayoutTests/svg/canvas/canvas-draw-image-globalalpha.html
[modify] https://crrev.com/477a9c21852a80e1e2b54e2e6ca9b23012ffbce7/third_party/WebKit/Source/core/xml/DocumentXMLTreeViewer.css
[modify] https://crrev.com/477a9c21852a80e1e2b54e2e6ca9b23012ffbce7/third_party/WebKit/Source/devtools/front_end/audits2/lighthouse/report-styles.css
[modify] https://crrev.com/477a9c21852a80e1e2b54e2e6ca9b23012ffbce7/third_party/WebKit/Source/devtools/front_end/audits2/lighthouse/templates.html

Project Member

Comment 82 by bugdroid1@chromium.org, Jan 31 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/511efa694bdf9fbed3dc83e3fa4cda12909ce2b6

commit 511efa694bdf9fbed3dc83e3fa4cda12909ce2b6
Author: Stephen McGruer <smcgruer@chromium.org>
Date: Wed Jan 31 16:42:25 2018

Add deprecation message for kDataUriHasOctothorpe

We are aiming to deprecate this feature in M67. This warning may have
some false positives (as it is legal to use '#' as a fragment
identifier), but I have yet to find a case in the wild of someone
actually doing that.

Intent: https://groups.google.com/a/chromium.org/d/msg/blink-dev/_g_HnAHkMPo/1DrejG5mAgAJ

Bug: 123004
Change-Id: Ibace7288ddb6a814f51faec85c47a49b0d69a273
Reviewed-on: https://chromium-review.googlesource.com/888762
Commit-Queue: Stephen McGruer <smcgruer@chromium.org>
Reviewed-by: Rick Byers <rbyers@chromium.org>
Reviewed-by: David Benjamin <davidben@chromium.org>
Cr-Commit-Position: refs/heads/master@{#533298}
[modify] https://crrev.com/511efa694bdf9fbed3dc83e3fa4cda12909ce2b6/third_party/WebKit/Source/core/frame/Deprecation.cpp
[modify] https://crrev.com/511efa694bdf9fbed3dc83e3fa4cda12909ce2b6/third_party/WebKit/Source/core/loader/FrameFetchContext.cpp

Labels: -M-62 M-67
Just keeping the bug up-to-date: 

i. Various Google properties have been updated and https://www.chromestatus.com/metrics/feature/timeline/popularity/2216 has dropped to 0.24%.

ii. The deprecation message will be in M66. Currently in canary.

iii. I intend to land the removal CL in early March, after M66 branches.
Project Member

Comment 84 by bugdroid1@chromium.org, Mar 19 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/23aafba1721fe9b9336f55a3b41623c959a43216

commit 23aafba1721fe9b9336f55a3b41623c959a43216
Author: Stephen McGruer <smcgruer@chromium.org>
Date: Mon Mar 19 16:55:38 2018

[url] Properly treat '#' as marking the start of the fragment in data URIs

This CL aligns Chromium with the URL spec, such that we consider '#' to
mark the end of the content and the start of the fragment section only.
GURL::GetContent was updated to reflect this, with a special case for
javascript URLs specifically (as their spec mentions including '#' in the
URL content).

Bug: 123004
Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation;master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs
Change-Id: I49c6f4d739a2dd42eecc9947f8e75071b84e9be7

TBR: boliu@chromium.org, pfeldman@chromium.org, thakis@chromium.org
Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation;master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs
Change-Id: I49c6f4d739a2dd42eecc9947f8e75071b84e9be7
Reviewed-on: https://chromium-review.googlesource.com/738395
Commit-Queue: Stephen McGruer <smcgruer@chromium.org>
Reviewed-by: Bo <boliu@chromium.org>
Reviewed-by: Mike West <mkwst@chromium.org>
Reviewed-by: Mihai Sardarescu <msarda@chromium.org>
Reviewed-by: Eugene But <eugenebut@chromium.org>
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Brett Wilson <brettw@chromium.org>
Cr-Commit-Position: refs/heads/master@{#544065}
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/android_webview/javatests/src/org/chromium/android_webview/test/AndroidViewIntegrationTest.java
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/android_webview/javatests/src/org/chromium/android_webview/test/AwContentsClientShouldOverrideUrlLoadingTest.java
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/android_webview/javatests/src/org/chromium/android_webview/test/AwContentsRenderTest.java
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/android_webview/javatests/src/org/chromium/android_webview/test/AwSettingsTest.java
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/chrome/browser/chromeos/fileapi/external_file_url_util.cc
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/chrome/browser/extensions/api/identity/gaia_web_auth_flow.cc
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/chrome/browser/resources/chromeos/chromevox/testing/common.js
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/chrome/renderer/autofill/password_generation_test_utils.cc
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/chrome/renderer/safe_browsing/threat_dom_details_browsertest.cc
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/content/browser/accessibility/accessibility_action_browsertest.cc
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/content/browser/accessibility/accessibility_win_browsertest.cc
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/content/browser/browser_side_navigation_browsertest.cc
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/content/browser/devtools/protocol/devtools_protocol_browsertest.cc
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/content/browser/renderer_host/input/composited_scrolling_browsertest.cc
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/content/browser/renderer_host/input/touch_input_browsertest.cc
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/content/browser/renderer_host/input/wheel_scroll_latching_browsertest.cc
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/content/browser/renderer_host/render_widget_host_view_browsertest.cc
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/content/public/test/render_view_test.cc
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/ios/chrome/browser/web/browsing_egtest.mm
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/ios/chrome/browser/web/navigation_egtest.mm
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/ios/chrome/browser/web/push_and_replace_state_navigation_egtest.mm
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/ios/chrome/browser/web/window_open_by_dom_egtest.mm
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/ios/net/protocol_handler_util_unittest.mm
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/ios/web/public/test/BUILD.gn
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/ios/web/public/test/http_server/BUILD.gn
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/ios/web/public/test/http_server/http_server.mm
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/ios/web/public/test/url_test_util.h
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/ios/web/test/BUILD.gn
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/ios/web/test/url_test_util.mm
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/net/base/data_url.cc
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/net/base/data_url_unittest.cc
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/third_party/WebKit/LayoutTests/external/wpt/css/css-shapes/shape-outside/shape-image/shape-image-002.html
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/third_party/WebKit/LayoutTests/external/wpt/css/css-shapes/shape-outside/shape-image/shape-image-005.html
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/third_party/WebKit/LayoutTests/external/wpt/fetch/data-urls/processing.any-expected.txt
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/third_party/WebKit/LayoutTests/external/wpt/fetch/data-urls/processing.any.worker-expected.txt
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/third_party/WebKit/LayoutTests/external/wpt/fetch/security/dangling-markup-mitigation-data-url.tentative.sub.html
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/third_party/WebKit/LayoutTests/external/wpt/html/semantics/scripting-1/the-script-element/execution-timing/077.html
[delete] https://crrev.com/15de70612a01d97219b3d07b5b4d7a16553d287d/third_party/WebKit/LayoutTests/external/wpt/url/data-uri-fragment-expected.txt
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/third_party/WebKit/LayoutTests/fast/backgrounds/background-image-relative-url-in-iframe-expected.html
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/third_party/WebKit/LayoutTests/http/tests/linkHeader/link-rel-import-css-rule-capital.html
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/third_party/WebKit/LayoutTests/inspector-protocol/debugger/message-channel-async-stack.js
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/third_party/WebKit/LayoutTests/loader/link-load-only-supported-stylesheet-types-datauri.html
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/third_party/WebKit/LayoutTests/shadow-dom/link-title.html
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/third_party/WebKit/LayoutTests/svg/custom/object-data-href.html
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/url/gurl.cc
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/url/gurl.h
[modify] https://crrev.com/23aafba1721fe9b9336f55a3b41623c959a43216/url/gurl_unittest.cc

Project Member

Comment 85 by bugdroid1@chromium.org, Mar 19 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/84f77307119f04c5e542c7a4e245c25f82d08a3c

commit 84f77307119f04c5e542c7a4e245c25f82d08a3c
Author: Tommy Nyquist <nyquist@chromium.org>
Date: Mon Mar 19 21:12:18 2018

Revert "[url] Properly treat '#' as marking the start of the fragment in data URIs"

This reverts commit 23aafba1721fe9b9336f55a3b41623c959a43216.

Reason for revert: Started failing CTS tests across all WebView platforms:
android.webkit.cts.WebViewTest#testRequestImageRef
android.webkit.cts.WebViewTest#testLoadDataWithBaseUrl

Original change's description:
> [url] Properly treat '#' as marking the start of the fragment in data URIs
> 
> This CL aligns Chromium with the URL spec, such that we consider '#' to
> mark the end of the content and the start of the fragment section only.
> GURL::GetContent was updated to reflect this, with a special case for
> javascript URLs specifically (as their spec mentions including '#' in the
> URL content).
> 
> Bug: 123004
> Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation;master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs
> Change-Id: I49c6f4d739a2dd42eecc9947f8e75071b84e9be7
> 
> TBR: boliu@chromium.org, pfeldman@chromium.org, thakis@chromium.org
> Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation;master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs
> Change-Id: I49c6f4d739a2dd42eecc9947f8e75071b84e9be7
> Reviewed-on: https://chromium-review.googlesource.com/738395
> Commit-Queue: Stephen McGruer <smcgruer@chromium.org>
> Reviewed-by: Bo <boliu@chromium.org>
> Reviewed-by: Mike West <mkwst@chromium.org>
> Reviewed-by: Mihai Sardarescu <msarda@chromium.org>
> Reviewed-by: Eugene But <eugenebut@chromium.org>
> Reviewed-by: David Benjamin <davidben@chromium.org>
> Reviewed-by: Brett Wilson <brettw@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#544065}

TBR=davidben@chromium.org,thakis@chromium.org,brettw@chromium.org,boliu@chromium.org,msarda@chromium.org,pfeldman@chromium.org,eugenebut@chromium.org,mkwst@chromium.org,smcgruer@chromium.org

Change-Id: Ib4cd66e4eae27a4868654e305796b98a7734ce20
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 123004
Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation;master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs
Reviewed-on: https://chromium-review.googlesource.com/969189
Reviewed-by: Tommy Nyquist <nyquist@chromium.org>
Commit-Queue: Tommy Nyquist <nyquist@chromium.org>
Cr-Commit-Position: refs/heads/master@{#544158}
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/android_webview/javatests/src/org/chromium/android_webview/test/AndroidViewIntegrationTest.java
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/android_webview/javatests/src/org/chromium/android_webview/test/AwContentsClientShouldOverrideUrlLoadingTest.java
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/android_webview/javatests/src/org/chromium/android_webview/test/AwContentsRenderTest.java
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/android_webview/javatests/src/org/chromium/android_webview/test/AwSettingsTest.java
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/chrome/browser/chromeos/fileapi/external_file_url_util.cc
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/chrome/browser/extensions/api/identity/gaia_web_auth_flow.cc
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/chrome/browser/resources/chromeos/chromevox/testing/common.js
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/chrome/renderer/autofill/password_generation_test_utils.cc
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/chrome/renderer/safe_browsing/threat_dom_details_browsertest.cc
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/content/browser/accessibility/accessibility_action_browsertest.cc
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/content/browser/accessibility/accessibility_win_browsertest.cc
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/content/browser/browser_side_navigation_browsertest.cc
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/content/browser/devtools/protocol/devtools_protocol_browsertest.cc
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/content/browser/renderer_host/input/composited_scrolling_browsertest.cc
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/content/browser/renderer_host/input/touch_input_browsertest.cc
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/content/browser/renderer_host/input/wheel_scroll_latching_browsertest.cc
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/content/browser/renderer_host/render_widget_host_view_browsertest.cc
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/content/public/test/render_view_test.cc
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/ios/chrome/browser/web/browsing_egtest.mm
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/ios/chrome/browser/web/navigation_egtest.mm
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/ios/chrome/browser/web/push_and_replace_state_navigation_egtest.mm
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/ios/chrome/browser/web/window_open_by_dom_egtest.mm
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/ios/net/protocol_handler_util_unittest.mm
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/ios/web/public/test/BUILD.gn
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/ios/web/public/test/http_server/BUILD.gn
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/ios/web/public/test/http_server/http_server.mm
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/ios/web/public/test/url_test_util.h
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/ios/web/test/BUILD.gn
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/ios/web/test/url_test_util.mm
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/net/base/data_url.cc
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/net/base/data_url_unittest.cc
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/third_party/WebKit/LayoutTests/external/wpt/css/css-shapes/shape-outside/shape-image/shape-image-002.html
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/third_party/WebKit/LayoutTests/external/wpt/css/css-shapes/shape-outside/shape-image/shape-image-005.html
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/third_party/WebKit/LayoutTests/external/wpt/fetch/data-urls/processing.any-expected.txt
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/third_party/WebKit/LayoutTests/external/wpt/fetch/data-urls/processing.any.worker-expected.txt
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/third_party/WebKit/LayoutTests/external/wpt/fetch/security/dangling-markup-mitigation-data-url.tentative.sub.html
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/third_party/WebKit/LayoutTests/external/wpt/html/semantics/scripting-1/the-script-element/execution-timing/077.html
[add] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/third_party/WebKit/LayoutTests/external/wpt/url/data-uri-fragment-expected.txt
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/third_party/WebKit/LayoutTests/fast/backgrounds/background-image-relative-url-in-iframe-expected.html
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/third_party/WebKit/LayoutTests/http/tests/linkHeader/link-rel-import-css-rule-capital.html
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/third_party/WebKit/LayoutTests/inspector-protocol/debugger/message-channel-async-stack.js
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/third_party/WebKit/LayoutTests/loader/link-load-only-supported-stylesheet-types-datauri.html
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/third_party/WebKit/LayoutTests/shadow-dom/link-title.html
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/third_party/WebKit/LayoutTests/svg/custom/object-data-href.html
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/url/gurl.cc
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/url/gurl.h
[modify] https://crrev.com/84f77307119f04c5e542c7a4e245c25f82d08a3c/url/gurl_unittest.cc

I believe that CTS test is wrong. It is loading a data URL using the WebView loadData API and including #s.
https://developer.android.com/reference/android/webkit/WebView.html#loadData(java.lang.String,%20java.lang.String,%20java.lang.String)

That API signature is honestly kind of a mess, but the documentation says:

"""
For all other values of encoding (including null) it is assumed that the data uses ASCII encoding for octets inside the range of safe URL characters and use the standard %xx hex encoding of URLs for octets outside that range. See RFC 3986 for more information.
"""

RFC 3986 marks '#' as reserved and thus must be escaped before being passed to loadData.

That suggests we should fix the CTS test. Alternatively, if we believe the breakage risk for WebView there is too high, I suppose loadData can be redefined to replace "#" with "%23" before assembling the data URL, though that is rather a hack.
The CTS test is definitely wrong, but the breakage was discovered ~5pm EST and I've been told the cost of the failing tests is high. As such, I approved a revert and plan to tackle fixing the CTS tests (whether personally or via collaboration with the Android team) tomorrow.

Sadly I actually had a partial revert CL *nearly* ready which would only revert the core parts of the CL rather than all of the tests I fixed in this one, but I wasn't expecting to have to revert within just a few hours :(. C'est la vie.
Blockedon: 823666
This is now blocked on fixing the CTS tests (internal bug b/76010914) and on issue 823666 (internal only, sorry) which is about a broken WebView app.

Both of those issues will have to be resolved before this can be re-landed. As per 823666, we should then also monitor the WebView UMA statistics to see the remaining impact.
Project Member

Comment 89 by bugdroid1@chromium.org, Apr 11 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d7843a4769214114c1fa55069976918b6d751b54

commit d7843a4769214114c1fa55069976918b6d751b54
Author: Stephen McGruer <smcgruer@chromium.org>
Date: Wed Apr 11 12:10:19 2018

Push kDataUriHasOctothorpe deprecation warning out to M68

M67 will be branching soon, and we will not be able to reland the CL to
properly handle octothorpes in data URIs by then.

Bug: 123004, 823666
Change-Id: Id990326e6a7a968ee0ab8a027ccfea4a6f4ece3f
Reviewed-on: https://chromium-review.googlesource.com/1000295
Reviewed-by: David Bokan <bokan@chromium.org>
Commit-Queue: Stephen McGruer <smcgruer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549865}
[modify] https://crrev.com/d7843a4769214114c1fa55069976918b6d751b54/third_party/blink/renderer/core/frame/deprecation.cc

Project Member

Comment 90 by bugdroid1@chromium.org, May 16 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d916d493946d116f0559b09339fad5c09520805c

commit d916d493946d116f0559b09339fad5c09520805c
Author: Stephen McGruer <smcgruer@chromium.org>
Date: Wed May 16 16:30:01 2018

Update LayoutTests to use '%23' instead of '#' in data URIs

This is a (very) partial reland of
https://chromium-review.googlesource.com/c/chromium/src/+/738395,
restoring only the changes to LayoutTests. This should be safe since
'%23' always has been a correct encoding of '#' and so should work with
the data URI code as it is today. It will also make any future re-land
of the core original CL easier.

Bug: 123004
Change-Id: I87126ea0e3fd39756e571a8e6cf966107e7f7209
Reviewed-on: https://chromium-review.googlesource.com/1048287
Reviewed-by: David Benjamin <davidben@chromium.org>
Commit-Queue: Stephen McGruer <smcgruer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#559130}
[modify] https://crrev.com/d916d493946d116f0559b09339fad5c09520805c/third_party/WebKit/LayoutTests/external/wpt/fetch/security/dangling-markup-mitigation-data-url.tentative.sub.html
[modify] https://crrev.com/d916d493946d116f0559b09339fad5c09520805c/third_party/WebKit/LayoutTests/external/wpt/html/semantics/scripting-1/the-script-element/execution-timing/077.html
[modify] https://crrev.com/d916d493946d116f0559b09339fad5c09520805c/third_party/WebKit/LayoutTests/fast/backgrounds/background-image-relative-url-in-iframe-expected.html
[modify] https://crrev.com/d916d493946d116f0559b09339fad5c09520805c/third_party/WebKit/LayoutTests/http/tests/linkHeader/link-rel-import-css-rule-capital.html
[modify] https://crrev.com/d916d493946d116f0559b09339fad5c09520805c/third_party/WebKit/LayoutTests/inspector-protocol/debugger/message-channel-async-stack.js
[modify] https://crrev.com/d916d493946d116f0559b09339fad5c09520805c/third_party/WebKit/LayoutTests/loader/link-load-only-supported-stylesheet-types-datauri.html
[modify] https://crrev.com/d916d493946d116f0559b09339fad5c09520805c/third_party/WebKit/LayoutTests/shadow-dom/link-title.html
[modify] https://crrev.com/d916d493946d116f0559b09339fad5c09520805c/third_party/WebKit/LayoutTests/svg/custom/object-data-href.html

Project Member

Comment 91 by bugdroid1@chromium.org, May 18 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1eb762aafda9c46b404b961effc7acacca8ebdd0

commit 1eb762aafda9c46b404b961effc7acacca8ebdd0
Author: Stephen McGruer <smcgruer@chromium.org>
Date: Fri May 18 17:04:44 2018

Update unittests to use '%23' instead of '#' in data URIs

This is a (very) partial reland of
https://chromium-review.googlesource.com/c/chromium/src/+/738395,
restoring only the changes to applicable unittests. This should be safe
since '%23' always has been a correct encoding of '#' and so should work
with the data URI code as it is today. It will also make any future
re-land of the core original CL easier.

Some unittests from the original CL were excluded, as the changes made
to them relied on the underlying behavior change.

TBR: pfeldman@chromium.org, thakis@chromium.org, ellyjones@chromium.org
Bug: 123004
Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation;master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs
Change-Id: I816fd90d744a1e12e2d9a8d6d0298834b55f2e57
Reviewed-on: https://chromium-review.googlesource.com/1062190
Reviewed-by: Stephen McGruer <smcgruer@chromium.org>
Reviewed-by: David Benjamin <davidben@chromium.org>
Commit-Queue: Stephen McGruer <smcgruer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#559928}
[modify] https://crrev.com/1eb762aafda9c46b404b961effc7acacca8ebdd0/chrome/browser/resources/chromeos/chromevox/testing/common.js
[modify] https://crrev.com/1eb762aafda9c46b404b961effc7acacca8ebdd0/chrome/renderer/autofill/password_generation_test_utils.cc
[modify] https://crrev.com/1eb762aafda9c46b404b961effc7acacca8ebdd0/chrome/renderer/safe_browsing/threat_dom_details_browsertest.cc
[modify] https://crrev.com/1eb762aafda9c46b404b961effc7acacca8ebdd0/content/browser/accessibility/accessibility_action_browsertest.cc
[modify] https://crrev.com/1eb762aafda9c46b404b961effc7acacca8ebdd0/content/browser/accessibility/accessibility_win_browsertest.cc
[modify] https://crrev.com/1eb762aafda9c46b404b961effc7acacca8ebdd0/content/browser/devtools/protocol/devtools_protocol_browsertest.cc
[modify] https://crrev.com/1eb762aafda9c46b404b961effc7acacca8ebdd0/content/browser/renderer_host/input/composited_scrolling_browsertest.cc
[modify] https://crrev.com/1eb762aafda9c46b404b961effc7acacca8ebdd0/content/browser/renderer_host/input/touch_input_browsertest.cc
[modify] https://crrev.com/1eb762aafda9c46b404b961effc7acacca8ebdd0/content/browser/renderer_host/input/wheel_scroll_latching_browsertest.cc
[modify] https://crrev.com/1eb762aafda9c46b404b961effc7acacca8ebdd0/content/browser/renderer_host/render_widget_host_view_browsertest.cc
[modify] https://crrev.com/1eb762aafda9c46b404b961effc7acacca8ebdd0/content/public/test/render_view_test.cc
[modify] https://crrev.com/1eb762aafda9c46b404b961effc7acacca8ebdd0/ios/net/protocol_handler_util_unittest.mm

Project Member

Comment 92 by bugdroid1@chromium.org, Jun 1 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2811b9664b1cc21597e2fb9e5801db5a73d8f4dd

commit 2811b9664b1cc21597e2fb9e5801db5a73d8f4dd
Author: Stephen McGruer <smcgruer@chromium.org>
Date: Fri Jun 01 18:58:53 2018

Push deprecation for kDataUriHasOctothorpe to M71

Before this can be deprecated we need to get a WebView UMA landed and
get data for it, and we need to then provide some sort of SDK quirk for
WebView based on the results. That will not happen in time for M68, or
probably even M69. Shooting for M71 to be safe.

Bug: 123004
Change-Id: Ia7fbe3223ab2b2a302eb4b3732f5070eb69e3820
Reviewed-on: https://chromium-review.googlesource.com/1075767
Reviewed-by: Rick Byers <rbyers@chromium.org>
Commit-Queue: Stephen McGruer <smcgruer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#563743}
[modify] https://crrev.com/2811b9664b1cc21597e2fb9e5801db5a73d8f4dd/third_party/blink/renderer/core/frame/deprecation.cc

Labels: Merge-Request-68 OS-Android OS-Chrome OS-Fuchsia OS-iOS OS-Linux OS-Mac OS-Windows
Release TPMs - requesting merge of https://chromium.googlesource.com/chromium/src/+/2811b9664b1cc21597e2fb9e5801db5a73d8f4dd to M68. This is a small change that just pushes the deprecation milestone for a feature from M68 to M71. It needs to be in M68 so that we don't claim to developers that a feature has been deprecated incorrectly.

It has soaked over the weekend in canary, but happy to let it soak longer - it just needs to merge before M68 releases :).
Project Member

Comment 94 by sheriffbot@chromium.org, Jun 4 2018

Labels: -Merge-Request-68 Hotlist-Merge-Review Merge-Review-68
This bug requires manual review: Reverts referenced in bugdroid comments after merge request.
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), kariahda@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: -Merge-Review-68 Merge-Approved-68
Approving merge for change in #93. Branch:3440
Project Member

Comment 96 by bugdroid1@chromium.org, Jun 4 2018

Labels: -merge-approved-68 merge-merged-3440
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d105221889ed95e14be1e68640d009b7406df136

commit d105221889ed95e14be1e68640d009b7406df136
Author: Stephen McGruer <smcgruer@chromium.org>
Date: Mon Jun 04 17:49:03 2018

Push deprecation for kDataUriHasOctothorpe to M71

Before this can be deprecated we need to get a WebView UMA landed and
get data for it, and we need to then provide some sort of SDK quirk for
WebView based on the results. That will not happen in time for M68, or
probably even M69. Shooting for M71 to be safe.

Bug: 123004
Change-Id: Ia7fbe3223ab2b2a302eb4b3732f5070eb69e3820
Reviewed-on: https://chromium-review.googlesource.com/1075767
Reviewed-by: Rick Byers <rbyers@chromium.org>
Commit-Queue: Stephen McGruer <smcgruer@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#563743}(cherry picked from commit 2811b9664b1cc21597e2fb9e5801db5a73d8f4dd)
Reviewed-on: https://chromium-review.googlesource.com/1085501
Reviewed-by: Stephen McGruer <smcgruer@chromium.org>
Cr-Commit-Position: refs/branch-heads/3440@{#140}
Cr-Branched-From: 010ddcfda246975d194964ccf20038ebbdec6084-refs/heads/master@{#561733}
[modify] https://crrev.com/d105221889ed95e14be1e68640d009b7406df136/third_party/blink/renderer/core/frame/deprecation.cc

smcgruer@, do you have an update for this issue? It a fairly highly starred Hotlist-Interop issue, currently at #20 in the full list of issues.
Sorry for the delay in getting back to this. We had been blocked on extremely high usage from the Webview side, but thankfully over the last few months this has reduced dramatically and is no longer considered blocking.

I need to take another pass at the UKM data for the Chrome side (since the UseCounter is still high) to confirm we are (reasonably) safe to remove for Chrome, and then will land the removal. 
That's great news, thank you smcgruer@!
Update: it appears from the Chrome side UKM that we are now looking at a long tail of less popular sites. Our hope is that the breakage on any one site will be minor (usually a SVG icon breaking) and easily fixed (replace '#' with '%23'), so I am cautiously going ahead with another attempt to fix this compat issue.

I will try to land the related CL this week; obviously this will miss M71 which is a little awkward (since the deprecation warning points to that as the removal point) but it should make M72.
Project Member

Comment 101 by bugdroid1@chromium.org, Oct 31

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b52ebdc80dde907896fdf8bafc231e30b348b30b

commit b52ebdc80dde907896fdf8bafc231e30b348b30b
Author: Stephen McGruer <smcgruer@chromium.org>
Date: Wed Oct 31 22:06:04 2018

[url] Properly treat '#' as marking the start of the fragment in data URIs

This CL aligns Chromium with the URL spec, such that we consider '#' to
mark the end of the content and the start of the fragment section only.
GURL::GetContent was updated to reflect this, with a special case for
javascript URLs specifically (as their spec mentions including '#' in
the URL content).

This is a reland of I49c6f4d739a2dd42eecc9947f8e75071b84e9be7. Recent data
shows that kDataUriHasOctothorpe is now rare on WebView, and the Chrome
side data has also shifted to be a long tail of smaller users. Plan is to
land this change again and see if anything breaks.

TBR=rdevlin.cronin@chromium.org,mlamouri@chromium.org,pfeldman@chromium.org,boliu@chromium.org

Bug: 123004
Change-Id: Ib72b8eef4bd61db4f2488e522d3d4cfcfa8a1a14
Reviewed-on: https://chromium-review.googlesource.com/c/1297172
Commit-Queue: Stephen McGruer <smcgruer@chromium.org>
Reviewed-by: Stephen McGruer <smcgruer@chromium.org>
Reviewed-by: Bo <boliu@chromium.org>
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Eugene But <eugenebut@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#604399}
[modify] https://crrev.com/b52ebdc80dde907896fdf8bafc231e30b348b30b/android_webview/javatests/src/org/chromium/android_webview/test/AndroidViewIntegrationTest.java
[modify] https://crrev.com/b52ebdc80dde907896fdf8bafc231e30b348b30b/android_webview/javatests/src/org/chromium/android_webview/test/AwContentsClientShouldOverrideUrlLoadingTest.java
[modify] https://crrev.com/b52ebdc80dde907896fdf8bafc231e30b348b30b/android_webview/javatests/src/org/chromium/android_webview/test/AwContentsRenderTest.java
[modify] https://crrev.com/b52ebdc80dde907896fdf8bafc231e30b348b30b/android_webview/javatests/src/org/chromium/android_webview/test/AwSettingsTest.java
[modify] https://crrev.com/b52ebdc80dde907896fdf8bafc231e30b348b30b/chrome/browser/extensions/api/identity/gaia_web_auth_flow.cc
[modify] https://crrev.com/b52ebdc80dde907896fdf8bafc231e30b348b30b/content/browser/display_cutout/display_cutout_browsertest.cc
[modify] https://crrev.com/b52ebdc80dde907896fdf8bafc231e30b348b30b/content/browser/navigation_browsertest.cc
[modify] https://crrev.com/b52ebdc80dde907896fdf8bafc231e30b348b30b/ios/chrome/browser/web/browsing_egtest.mm
[modify] https://crrev.com/b52ebdc80dde907896fdf8bafc231e30b348b30b/ios/chrome/browser/web/navigation_egtest.mm
[modify] https://crrev.com/b52ebdc80dde907896fdf8bafc231e30b348b30b/ios/chrome/browser/web/push_and_replace_state_navigation_egtest.mm
[modify] https://crrev.com/b52ebdc80dde907896fdf8bafc231e30b348b30b/ios/chrome/browser/web/window_open_by_dom_egtest.mm
[modify] https://crrev.com/b52ebdc80dde907896fdf8bafc231e30b348b30b/ios/web/public/test/BUILD.gn
[modify] https://crrev.com/b52ebdc80dde907896fdf8bafc231e30b348b30b/ios/web/public/test/http_server/BUILD.gn
[modify] https://crrev.com/b52ebdc80dde907896fdf8bafc231e30b348b30b/ios/web/public/test/http_server/http_server.mm
[modify] https://crrev.com/b52ebdc80dde907896fdf8bafc231e30b348b30b/ios/web/public/test/url_test_util.h
[modify] https://crrev.com/b52ebdc80dde907896fdf8bafc231e30b348b30b/ios/web/test/BUILD.gn
[modify] https://crrev.com/b52ebdc80dde907896fdf8bafc231e30b348b30b/ios/web/test/url_test_util.mm
[modify] https://crrev.com/b52ebdc80dde907896fdf8bafc231e30b348b30b/net/base/data_url.cc
[modify] https://crrev.com/b52ebdc80dde907896fdf8bafc231e30b348b30b/net/base/data_url_unittest.cc
[delete] https://crrev.com/453adc546986eaa9cca766af9a70042f7b506309/third_party/WebKit/LayoutTests/css3/blending/background-blend-mode-svg-expected.txt
[delete] https://crrev.com/453adc546986eaa9cca766af9a70042f7b506309/third_party/WebKit/LayoutTests/css3/viewport-percentage-lengths/vh-resize-expected.txt
[modify] https://crrev.com/b52ebdc80dde907896fdf8bafc231e30b348b30b/third_party/WebKit/LayoutTests/external/wpt/fetch/data-urls/processing.any-expected.txt
[modify] https://crrev.com/b52ebdc80dde907896fdf8bafc231e30b348b30b/third_party/WebKit/LayoutTests/external/wpt/fetch/data-urls/processing.any.worker-expected.txt
[modify] https://crrev.com/b52ebdc80dde907896fdf8bafc231e30b348b30b/third_party/WebKit/LayoutTests/external/wpt/html/semantics/scripting-1/the-script-element/execution-timing/077.html
[delete] https://crrev.com/453adc546986eaa9cca766af9a70042f7b506309/third_party/WebKit/LayoutTests/external/wpt/url/data-uri-fragment-expected.txt
[delete] https://crrev.com/453adc546986eaa9cca766af9a70042f7b506309/third_party/WebKit/LayoutTests/svg/as-background-image/tiled-background-image-expected.txt
[modify] https://crrev.com/b52ebdc80dde907896fdf8bafc231e30b348b30b/third_party/blink/renderer/core/frame/deprecation.cc
[modify] https://crrev.com/b52ebdc80dde907896fdf8bafc231e30b348b30b/third_party/blink/renderer/core/loader/frame_fetch_context.cc
[modify] https://crrev.com/b52ebdc80dde907896fdf8bafc231e30b348b30b/url/gurl.cc
[modify] https://crrev.com/b52ebdc80dde907896fdf8bafc231e30b348b30b/url/gurl.h
[modify] https://crrev.com/b52ebdc80dde907896fdf8bafc231e30b348b30b/url/gurl_unittest.cc

Showing comments 3 - 102 of 102 Older

Sign in to add a comment