| commit | 14aed3fa863816c48cf03dedc6154631d2a0d57f | [log] [tgz] |
|---|---|---|
| author | Vaclav Brozek <vabr@chromium.org> | Thu May 06 04:40:26 2021 |
| committer | Chromium LUCI CQ <chromium-scoped@luci-project-accounts.iam.gserviceaccount.com> | Thu May 06 04:40:26 2021 |
| tree | 3a4b93a3fb2f37601a5cf46c8265f83e3b0f3bb5 | |
| parent | 97bb4ef64c29fed61e544a0fdeda96218358463c [diff] |
Reland Canonicalise file:///./s: as file:///S: on Win The original CL https://chromium-review.googlesource.com/c/chromium/src/+/2860002 was reverted, because of a missed update in one test expectation, which only showed on Win 7. In the meantime, a sync from WPT resolved that failing expectation (https://chromium-review.googlesource.com/c/chromium/src/+/2871329) so this CL also undoes the Win7 disabling of the test (https://chromium-review.googlesource.com/c/chromium/src/+/2874645). Original CL description: ============ Canonicalise file:///./s: as file:///S: on Win Chrome on Windows converts drive letters to upper case. Currently it only recognises drive letters appearing at the start of the path, optionally after a block of slashes. This leads to an inconsistency, where canonicalized URLs are themselves not canonical. Example: 1. file:///./s: canonicalizes as file:///s:, because the initial "s:" is not recognised as a drive letter (there is "." in the path prefix preceding it). 2. However, file:///s: itself canonicalizes as file:///S:, because now the "s:" is at the beginning and thus recognised as a drive letter and converted to upper case. That is bad, because canonicalzed URLs must be canonical, following their very definition. The associated bug https://crbug.com/1083031 discusses various approaches to fix this, and the consensus among domenic@, rsleevi@ and vabr@ was that the least bad solution to ensure that canonicalizer URLs are canonical is to treat each drive letter specification in the path as such as long as the path segment preceding it has the canonical form "/". This fixes the above problem with the non-canonical results of canonicalization. The fix comes with a cost of increasing the number of failing web conformance tests for Chrome on Windows. However, it does not really create a new problem: First, already today, Chrome on Win canonicalizes file://////s: as file:///S:, while outside of Win the result is file:///s:. Second, already today, Chrome on Win canonicalizes file:///s: as file:///S:. This is, in fact, _the_ problem and has been raised in https://github.com/whatwg/url/issues/515. ============ Bug: 1083031 Bug: 1205779 Change-Id: I40abdbf0e260fc4d9f1c908450b4eb2541b5b10a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2874649 Auto-Submit: Vaclav Brozek <vabr@chromium.org> Commit-Queue: Mike West <mkwst@chromium.org> Reviewed-by: Domenic Denicola <domenic@chromium.org> Reviewed-by: Mike West <mkwst@chromium.org> Cr-Commit-Position: refs/heads/master@{#879692}
Chromium is an open-source browser project that aims to build a safer, faster, and more stable way for all users to experience the web.
The project's web site is https://www.chromium.org.
To check out the source code locally, don't use git clone! Instead, follow the instructions on how to get the code.
Documentation in the source is rooted in docs/README.md.
Learn how to Get Around the Chromium Source Code Directory Structure .
For historical reasons, there are some small top level directories. Now the guidance is that new top level directories are for product (e.g. Chrome, Android WebView, Ash). Even if these products have multiple executables, the code should be in subdirectories of the product.