Status Update
No update yet.
Comments
ma...@gmail.com
ja...@gmail.com
Working examples that still result in a call to custom protocol handler
proto://asdf
proto://asdf:
Broken examples that result in either a search (instead of navigation via custom protocol handler), or an "about:blank#blocked" tab
proto://asdf:-
proto://asdf:asdf
ja...@gmail.com
ru...@gmail.com
Does anyone know of any way for us to administratively push this feature disablement en masse? We've got a primary LoB app that has lost significant functionality due to this "feature" and would like to be able to admin-push a setting change to get functionality back. Any windows GPO or reg key I can use to tell all our corporate Chrome installs to go back to old-style opaque path handling?
os...@tgk-jp.com
After setting the Chrome startup option "--disable-features=StandardCompliantNonSpecialSchemeURLParsing"
I confirmed that it has returned to its previous behavior.
ba...@chromium.org
hayato@: Could you take a look at this?
ha...@chromium.org
Thanks for the reports.
I've looked into the problem, and it seems like a regression introduced in M130.
I'm working on a fix – you can check it out here:
I chatted with TPM (@denomoto) today. While the M131 branch is already cut, we may aim to merge the fix for M131.
However, this isn't set in stone yet. We'll be monitoring how severely this regression is affecting users.
I might share more details next week as we learn more.
ap...@google.com
Project: chromium/src
Branch: main
Author: Hayato Ito <
Link:
Fix a regression on non-special URL, like "git:\opaque\path"
Expand for full commit details
Fix a regression on non-special URL, like "git:\\opaque\\path"
Chrome M130 supports non-special URL, however, a regression is reported
at http://crbug.com/373928202.
The summary is:
Chrome <= 129:
| No | URL | valid url? | url.hostname | url.path |
|----+------------------+------------+--------------+----------------|
| 1 | TEST://PC/FOLDER | valid | "" | "//PC/FOLDER" |
| 2 | TEST://PC\FOLDER | valid | "" | "//PC\FOLDER" |
| 3 | TEST:\\PC\FOLDER | valid | "" | "\\PC\FOLDER" |
| 4 | TEST:\\PC | valid | "" | "\\PC" |
Chrome 130:
| No | URL | valid url? | url.hostname | url.path |
|----+------------------+------------+--------------+---------------|
| 1 | TEST://PC/FOLDER | valid | "pc" | "/FOLDEDR" |
| 2 | TEST://PC\FOLDER | invalid | - | - |
| 3 | TEST:\\PC\FOLDER | invalid | - | - |
| 4 | TEST:\\PC | valid | "pc" | "" |
URL Standard (expected behaviors)
| No | URL | valid url? | url.hostname | url.path |
|----+------------------+------------+--------------+---------------|
| 1 | TEST://PC/FOLDER | valid | "pc" | "/FOLDEDR" |
| 2 | TEST://PC\FOLDER | invalid | - | - |
| 3 | TEST:\\PC\FOLDER | valid | "" | "\\PC\FOLDER" |
| 4 | TEST:\\PC | valid | "" | "\\PC" |
The problems is URL No.3 or No4, where "\\" (two backslashes) follows
after "scheme:", for which Chrome M130 is not spec-compliant.
These URLs should be a valid opaque path URL, however, Chrome M130
treat them wrongly.
The reason:
The current (wrong) URL parser counts backslahses as well as slashes
after "scheme:". This behavior is the correct behavior for a special
URL, like "https:\\PC\\FOLDER", but NOT for non-special URLs, like
"TEST:\\PC\\FOLDER", unfortunately.
For your reference, the URL Standard says that at the following place:
https://url.spec.whatwg.org/#scheme-state
> 7. Otherwise, if url is special, set state to special authority
> slashes state.
> 8. Otherwise, if remaining starts with an U+002F (/), set state to
> path or authority state and increase pointer by 1.
> 9. Otherwise, set url’s path to the empty string and set state to
> opaque path state.
It's a bit cryptic, but if you read this part (and other parts too)
carefully, it says so. :(
Unfortunately, the current WPT doesn't cover these test cases, so we
didn't notice this regression.
This CL fixes a regression by implement that URL standard part, and
also add WPT tests to prevent a regression.
Bug: 40063064,373928202
Change-Id: Ia5ba5ff16426893c735775c62b7044842d16b46d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5939018
Reviewed-by: Adam Rice <ricea@chromium.org>
Commit-Queue: Hayato Ito <hayato@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1370488}
Files:
- M
third_party/blink/web_tests/external/wpt/url/resources/urltestdata.json - M
url/third_party/mozilla/url_parse.cc - M
url/url_parse_internal.h
Hash: a2d10d8f8533f83d48c49f0d5603a33b6052d17e
Date: Fri Oct 18 10:56:16 2024
ja...@gmail.com
workstationutuility://action=ADD&id=22134454844322&returnURL=
However, Chrome now strips the colon and we receive an invalid return URL like this:
workstationutuility://action=ADD&id=22134454844322&returnURL=https//
I can confirm that the Chrome startup option "--disable-features=StandardCompliantNonSpecialSchemeURLParsing" resolves the issue as a temporary fix. This affects numerous applications that interact with the browser, so we are hoping there will be a fix pushed to resolve this use case.
ga...@gmail.com
We use OFS:// follower by a link
OFS://
We changed our software to correct the link and still work however there might be other scenarios that we didn't handle.
Hoping for a fix soon or at least a way to escape characters and rules what to avoid in links etc.
ha...@chromium.org
For the original reporter (
The CL,
For other reported issues (
These seem like different problems than the original report (
I'm closing this issue now since closing an issue is a requirement to send a merge request.
pe...@google.com
*This merge request uses Chrome's new merge process. Find more information at
M131 merge request created.
Please update crbug/374638498 to have this merge reviewed.
ho...@gmail.com
It´s same behavior in MS Edge and Google Chrome browser.
Please bring back old function with 131 or a regular admin setting.
ja...@gmail.com
localexplorer:\\server\some path\document.docx
Chrome 130 has broken this.
1j...@gmail.com
ma...@gmail.com
Is there a way to set --disable-features=StandardCompliantNonSpecialSchemeURLParsing as a Registry Key
on the impacted Machines?
@comment17: how you managed this?
Thanks
ja...@gmail.com
Update to my original comment @comment18: We control the internal app that generates the URLs, so we're working to fix the links. A general URL encode method in your given language can fix the issue if you control the link generation. Specifically for us, on .NET 4.5, Uri.EscapeDataString(string) is the correct method call that seems to generate URLs that Chrome likes. HtmlUtility.UrlEncode() does not work correctly.
ap...@google.com
Project: chromium/src
Branch: refs/branch-heads/6778
Author: Hayato Ito <
Link:
Fix a regression on non-special URL, like "git:\opaque\path"
Expand for full commit details
Fix a regression on non-special URL, like "git:\\opaque\\path"
Chrome M130 supports non-special URL, however, a regression is reported
at http://crbug.com/373928202.
The summary is:
Chrome <= 129:
| No | URL | valid url? | url.hostname | url.path |
|----+------------------+------------+--------------+----------------|
| 1 | TEST://PC/FOLDER | valid | "" | "//PC/FOLDER" |
| 2 | TEST://PC\FOLDER | valid | "" | "//PC\FOLDER" |
| 3 | TEST:\\PC\FOLDER | valid | "" | "\\PC\FOLDER" |
| 4 | TEST:\\PC | valid | "" | "\\PC" |
Chrome 130:
| No | URL | valid url? | url.hostname | url.path |
|----+------------------+------------+--------------+---------------|
| 1 | TEST://PC/FOLDER | valid | "pc" | "/FOLDEDR" |
| 2 | TEST://PC\FOLDER | invalid | - | - |
| 3 | TEST:\\PC\FOLDER | invalid | - | - |
| 4 | TEST:\\PC | valid | "pc" | "" |
URL Standard (expected behaviors)
| No | URL | valid url? | url.hostname | url.path |
|----+------------------+------------+--------------+---------------|
| 1 | TEST://PC/FOLDER | valid | "pc" | "/FOLDEDR" |
| 2 | TEST://PC\FOLDER | invalid | - | - |
| 3 | TEST:\\PC\FOLDER | valid | "" | "\\PC\FOLDER" |
| 4 | TEST:\\PC | valid | "" | "\\PC" |
The problems is URL No.3 or No4, where "\\" (two backslashes) follows
after "scheme:", for which Chrome M130 is not spec-compliant.
These URLs should be a valid opaque path URL, however, Chrome M130
treat them wrongly.
The reason:
The current (wrong) URL parser counts backslahses as well as slashes
after "scheme:". This behavior is the correct behavior for a special
URL, like "https:\\PC\\FOLDER", but NOT for non-special URLs, like
"TEST:\\PC\\FOLDER", unfortunately.
For your reference, the URL Standard says that at the following place:
https://url.spec.whatwg.org/#scheme-state
> 7. Otherwise, if url is special, set state to special authority
> slashes state.
> 8. Otherwise, if remaining starts with an U+002F (/), set state to
> path or authority state and increase pointer by 1.
> 9. Otherwise, set url’s path to the empty string and set state to
> opaque path state.
It's a bit cryptic, but if you read this part (and other parts too)
carefully, it says so. :(
Unfortunately, the current WPT doesn't cover these test cases, so we
didn't notice this regression.
This CL fixes a regression by implement that URL standard part, and
also add WPT tests to prevent a regression.
(cherry picked from commit a2d10d8f8533f83d48c49f0d5603a33b6052d17e)
Bug: 40063064,373928202
Fixed: 374638498
Change-Id: Ia5ba5ff16426893c735775c62b7044842d16b46d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5939018
Reviewed-by: Adam Rice <ricea@chromium.org>
Commit-Queue: Hayato Ito <hayato@chromium.org>
Cr-Original-Commit-Position: refs/heads/main@{#1370488}
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5959684
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/branch-heads/6778@{#723}
Cr-Branched-From: b21671ca172dcfd1566d41a770b2808e7fa7cd88-refs/heads/main@{#1368529}
Files:
- M
third_party/blink/web_tests/external/wpt/url/resources/urltestdata.json - M
url/third_party/mozilla/url_parse.cc - M
url/url_parse_internal.h
Hash: a26690025b4e8ebfa6f953c4c09515938a431903
Date: Thu Oct 24 03:33:28 2024
ha...@google.com
For the original reporter (
The merge request was approved and the fix for your issue was merged into M131 (
For everyone else,
FYI. I've filed a meta issue,
While you're welcome to continue the discussion here for a while, it might be best to move it to the meta issue eventually, because this issue number (
vd...@google.com
Verified the fix on latest Beta M131 #131.0.6778.24 using Mac 14.7, Windows and Linux as per
Hence, the fix is working as expected and adding verified labels
Attaching screencasts for reference
Thanks..!!
1j...@gmail.com
In addition, and if ECS is disabled through policy, a code change to temporarily disable this feature is being checked in, which will be included in an upcoming Edge 130 Stable release. An update will be provided once Microsoft determines which Edge stable release will address the issue.
Note: This feature is planned to be turned on again in Microsoft Edge version 133. Admins can use the StandardCompliantNonSpecialSchemeURLParsing feature flag to explicitly enable the feature in the Edge Canary Channel. Customers are encouraged to test the impact of this upcoming feature and prepare for the change in behavior."
Source:
ty...@gmail.com
RE:
Google Chrome 131.0.6778.70 (Official Build) (64-bit) (cohort: Stable Installs & Version Pins)
Revision 92b6e81c7548ac424b567279d200a3f79b50e4bc-refs/branch-heads/6778@{#2142}
OS Windows 10 Version 22H2 (Build 19045.5011)
JavaScript V8 13.1.201.8
User Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36
Command Line "C:\Program Files\Google\Chrome\Application\chrome.exe" --profile-directory="Profile 1" --flag-switches-begin --flag-switches-end
When adding back the disable switch it works
Google Chrome 131.0.6778.70 (Official Build) (64-bit) (cohort: Stable Installs & Version Pins)
Revision 92b6e81c7548ac424b567279d200a3f79b50e4bc-refs/branch-heads/6778@{#2142}
OS Windows 10 Version 22H2 (Build 19045.5011)
JavaScript V8 13.1.201.8
User Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36
Command Line "C:\Program Files\Google\Chrome\Application\chrome.exe" --profile-directory="Profile 1" --disable-features=StandardCompliantNonSpecialSchemeURLParsing --flag-switches-begin --flag-switches-end
edit:
be...@phalanx.at
w2...@gmail.com
sc...@gmail.com
I had the same issue. Fixing the link worked for me. Replace Backslash with %5C.
Not working:
myapp://\\server\path\folder
This works:
myapp://%5C%5Cserver%5Cpath%5Cfolder
Description
Steps to reproduce the problem
*Note: Use a backslash "" instead of a slash "/".
Problem Description
With the update to Chrome version 130, the handling of Non-special URLs has changed as part of the improvements.
While I think this is a good attempt, I encountered one issue.
The custom scheme links I created no longer work.
Specifically, when I click the following link:
<a href="TEST:\\PC\FOLDER">TEST</a>,
it redirects to the "about:blank#blocked" page.
After trying several things, I found the following results:
OK: <a href="TEST://PC/FOLDER">TEST</a>
NG: <a href="TEST://PC\FOLDER">TEST</a>
NG: <a href="TEST:\\PC\FOLDER">TEST</a>
OK: <a href="TEST:\\PC">TEST</a>
It seems that using backslashes as folder separators causes the link to redirect to "about:blank#blocked".
Honestly, this feels like a regression rather than an improvement.
I would like to use backslashes as folder separators.
Would it be possible to fix this issue?
Summary
Custom scheme links with backslashes in Chrome 130 redirect to 'about:blank#blocked'."
Custom Questions
Example URL:
Our company's intranet homepage
Does the problem occur on multiple sites?
No - Just that one URL
Is it a problem with a plugin?
No - It's the browser itself
Does this work in other browsers?
Yes - This is just a Chromium problem
Additional Data
Category: Content
Chrome Channel: Stable
Regression: Yes