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

Issue 659550 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Nov 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Regression: Error page is not seen on navigating to 'chrome://,./' page.

Reported by vvishwak...@etouch.net, Oct 26 2016

Issue description

Version: 56.0.2900.0 (Official Build) canary 1e4fbec3b5701d9f605e88f14dafa442be98b648-refs/heads/master@{#427219} (32/64-bit)
OS: Windows (7,8,10), Mac(10.10.5, 10.11.4), Linux (14.04 LTS)

What steps will reproduce the problem?
1) Launch chrome, open NTP, go to ‘chrome://,./‘ and observe.

Error page is not seen on navigating to chrome://,./ page.

Error page should be seen on navigating to chrome://,./ page.

This is a Regression issue broken in M-56, will soon update other info
Manual bisect:
Good build: 56.0.2888.0
Bad build: 56.0.2890.0
 
errorpage_actual.mov
1.7 MB Download
error_expected.mov
1.2 MB Download
Labels: -Pri-1 -hasbisect hasbisect-per-revision Pri-2
Owner: csharrison@chromium.org
Status: Assigned (was: Unconfirmed)
Per-revision bisect result:
-------------------------
Good build: 56.0.2888.0 (Revision 424625)
Bad build: 56.0.2890.0 (Revision 425218)

You are probably looking for a change made after 424642 (known good), but no later than 424643 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/6731ece446bd9b4f7fb0ed44492ab58ebc17fb88..edf893fee347ad915af17f4abbf19e19e3131898

https://chromium.googlesource.com/chromium/src/+/edf893fee347ad915af17f4abbf19e19e3131898, csharrison@ could you please check the issue.


Cc: nick@chromium.org
This looks reproducible even with "chrome://,/"

+nick
It looks like the URL is properly rewriting to chrome://%2C/, but then rewriting that to an about:blank navigation (so the net stack doesn't give us an INVALID_URL error). Not sure how my change is involved yet but it probably is.

Will try to pull up a debugger today and investigate.
Labels: ReleaseBlock-Stable
Adding RB label as this is a recent regression.
Cc: brettw@chromium.org
Actually this hits a DCHECK on SchemeHostPort assuming data coming from the security origin is already canonicalized.

In particular, it looks like SecurityOrigin is sending lowercased escape characters, where we consider "canonical urls" to be uppercased escape characters! Brett, this is exactly what we were talking about hours ago in this revision:
https://codereview.chromium.org/2447293002/

In fact, if we stop calling lower() on host() in constructing SecurityOrigins, we fix this bug :)

Some other weirdness if happening that I'll try to figure out, but I think we can solve this problem in the linked revision, with more test cases.
Project Member

Comment 5 by bugdroid1@chromium.org, Oct 31 2016

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

commit 2874fa423262879ed27036f716f3e96a5f8e863f
Author: csharrison <csharrison@chromium.org>
Date: Mon Oct 31 18:52:03 2016

Don't call lower() on KURL protocol/host

KURL should already canonicalize the scheme and host. This is just
needless work and causes confusion to readers who may get the
wrong impression about code invariants.

Additionally, calling lower() on the host is a bug, because we
canonicalize escape characters to uppercase, but lower() reverts
that and brings them back to lowercase, effecively rendering the
host not canonical anymore!

This is a pre-req for removing CaseFoldingHash from SchemeRegistry.

BUG= 659550 ,348655

Review-Url: https://codereview.chromium.org/2447293002
Cr-Commit-Position: refs/heads/master@{#428762}

[modify] https://crrev.com/2874fa423262879ed27036f716f3e96a5f8e863f/content/child/blink_platform_impl_unittest.cc
[add] https://crrev.com/2874fa423262879ed27036f716f3e96a5f8e863f/third_party/WebKit/LayoutTests/http/tests/security/document-domain-canonicalizes.html
[modify] https://crrev.com/2874fa423262879ed27036f716f3e96a5f8e863f/third_party/WebKit/LayoutTests/http/tests/security/document-domain-invalid.html
[modify] https://crrev.com/2874fa423262879ed27036f716f3e96a5f8e863f/third_party/WebKit/Source/core/dom/Document.cpp
[modify] https://crrev.com/2874fa423262879ed27036f716f3e96a5f8e863f/third_party/WebKit/Source/platform/weborigin/KURL.cpp
[modify] https://crrev.com/2874fa423262879ed27036f716f3e96a5f8e863f/third_party/WebKit/Source/platform/weborigin/KURLTest.cpp
[modify] https://crrev.com/2874fa423262879ed27036f716f3e96a5f8e863f/third_party/WebKit/Source/platform/weborigin/KnownPorts.cpp
[modify] https://crrev.com/2874fa423262879ed27036f716f3e96a5f8e863f/third_party/WebKit/Source/platform/weborigin/OriginAccessEntry.cpp
[modify] https://crrev.com/2874fa423262879ed27036f716f3e96a5f8e863f/third_party/WebKit/Source/platform/weborigin/SecurityOrigin.cpp
[modify] https://crrev.com/2874fa423262879ed27036f716f3e96a5f8e863f/third_party/WebKit/Source/platform/weborigin/SecurityOrigin.h
[modify] https://crrev.com/2874fa423262879ed27036f716f3e96a5f8e863f/third_party/WebKit/Source/platform/weborigin/SecurityOriginTest.cpp

Labels: TE-Verified-M56 TE-Verified-56.0.2906.0
Tested the issue on Windows 7,Mac 10.11.4,Linux Ubuntu 14.04 using chrome Dev version-56.0.2906.0 with the steps mentioned in comment #0.Issue working as expected.

Please find the attached screen cast for the same.

Adding TE-Verified labels.

Thanks,

659550.mov
2.1 MB Download
Status: Fixed (was: Assigned)

Sign in to add a comment