New issue
Advanced search Search tips

Issue 783382 link

Starred by 5 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: iOS
Pri: 3
Type: Task

Blocked on:
issue 767092
issue 734150

Blocking:
issue 738020



Sign in to add a comment

Remove gCrWeb override of history.pushState and replaceState

Project Member Reported by danyao@chromium.org, Nov 9 2017

Issue description

The pushState and replaceState override in https://cs.chromium.org/chromium/src/ios/web/web_state/js/resources/navigation.js have two use cases:
1) create navigation entries for these operations
2) differentiate those same-documentation navigations that are state navigations from those that are fragment navigations

(1) is no longer needed after switching to WKBasedNavigationManager: crbug.com/734150

The need for (2) is historical: WebStateObserver::DidStartLoading is only fired for fragment changes not state changes. This is a bug, but the behavior has to be preserved because PageCount stat relies on this. This will be fixed after crbug.com/767092.

Remove the pushState / replaceState overrides when the above is fixed.
 
Cc: eugene...@chromium.org
Will this fix the problem we are having with pushState sometimes not registering in the history state. I thought my problem had something to do with WKWebView, but I tried both Firefox Browser and Opera Mini browser which also uses WKWebView and they works flawlessy. It seems like it is only Chrome in iOS that doesnt work.
I've written at StackOverflow about this.
I think it has something to do with that it needs an interaction to fully register the pushState.

https://stackoverflow.com/questions/47263116/history-pushstate-not-working-in-chrome-on-ios-when-executing-without-an-interac

Comment 3 by danyao@chromium.org, Nov 14 2017

It's (1) that's causing the problem you see. Chrome on iOS manages its own history state, whereas Firefox Browser (probably Opera Mini as well) uses WKWebView's history state. I'm working on a big refactor to make Chrome use WKWebView history state (crbug.com/734150) and it should fix your problem.

Comment 4 by danyao@chromium.org, Nov 17 2017

Labels: Proj-WKBackForwardList
May I ask if there is an ETA on crbug.com/734150 so that I can report back to my team?
It's a large refactor of the navigation layer that's still under
development. My current target is to have this fully enabled in M66 (so
mid-2018).
Blocking: 738020
Status: Assigned (was: Available)

Sign in to add a comment