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

Issue 618989 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

history.pushState() with "?" not working for file:// URLs

Reported by martin.h...@gmail.com, Jun 10 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.84 Safari/537.36

Steps to reproduce the problem:
1. Run Chrome/Chromium with or without --allow-file-access-from-files (same result)
2. Load an HTML5 page from a file:// URL, let's say file:///D:/folder/file.html
3. Call history.pushState({}, 'dummyTitle', '#foo=bar')
4. Call history.pushState({}, 'dummyTitle', '?foo=bar')
5. Call history.pushState({}, 'dummyTitle', 'file:///D:/folder/file.html?foo=bar')

What is the expected behavior?
All three calls work. This was the behavior until at least Chromium v49 (maybe also v50).

What went wrong?
Only call in step 3. (with '#' character) works.

Calls in step 4. and 5. fail: Uncaught DOMException: Failed to execute 'pushState' on 'History': A history state object with URL 'file:///D:/folder/file.html?foo=bar' cannot be created in a document with origin 'null' and URL 'file:///D:/Dev/2GoRC_2_access/web/2.1.0.0/partials/unsupportedbrowser_fileurl.html'

Did this work before? Yes v49.0

Chrome version: 53.0.2764.0  Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: 22.0.0.185
 
Affects all of these:
Chrome stable, Version 51.0.2704.84 m
Chromium portable, Version 52.0.2739.0
Chrome Canary, Version 53.0.2764.0 canary (64-bit)
Portable web applications would profit from fixing this
Components: -Blink Blink>Loader
Cc: mkwst@chromium.org
mkwst@, could this be related to https://codereview.chromium.org/1632513002?

Comment 5 by pxinc...@gmail.com, Jun 12 2016

The issue is caused by "equalIgnoringFragmentIdentifier()".

I sumbit the patch https://codereview.chromium.org/2060093002/ .

By testing , it is ok .

Comment 6 by mkwst@chromium.org, Jun 12 2016

Status: Started (was: Unconfirmed)
In https://bugs.chromium.org/p/chromium/issues/detail?id=528681, we carved out an exception for pushing fragment state for `file://` URLs. It's probably reasonable to extend that to include query state as well. I don't think we should extend it to include path changes, however, for the reasons outlined in that bug.

Thanks for providing a patch; I'll take a look at it shortly.
Thanks for investigating this. Would be great to have the issue fixed soon!
Status: Available (was: Started)
This issue has been marked as started, but has no owner. Making available.

Sign in to add a comment