New issue
Advanced search Search tips

Issue 859505 link

Starred by 2 users
Status: Available
Owner: ----
Cc:
mard...@chromium.org
gambard@chromium.org
eugene...@chromium.org
ios-bugs@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: iOS
Pri: 2
Type: Bug



Sign in to add a comment

No back button available on slow pageloads before the navigation is committed

Project Member Reported by stkhapugin@chromium.org, Jul 2 
Steps to repro:

1. Open an NTP
2. In iOS Settings, search for network profiler, enable it with 100% loss preset
3. Return to Chrome
4. Tap on any of the NTP suggestions

before the first network request times out, you are in a state where:
1. there is no content
2. there is no back button to navigate to NTP
3. on phones, there is no stop or reload button, 
so as a user, I am pretty confused in how to exit this state. 

Seems related to crbug.com/845403, but shows a different side of the issue: instead of which page to reload, I'm more concerned with having nowhere to go back, yet already having left the previous page.

Comment 1 by danyao@chromium.org, Jul 4

Cc: eugene...@chromium.org
Labels: Proj-WKBackForwardList
With Bijou, the stop button is visible in the ... menu. Clicking on it takes user back to NTP, which seems to me is reasonable.

Without Bijou, the reload button is visible in the menu, but it doesn't change to the stop button until the back button becomes visible. This seems wrong, because |canGoBack| changes to true in |didCommitNavigation|. The stop button ought to be shown when loading starts.

Comment 2 by mard...@chromium.org, Jul 5 

I agree that with Bijou the situation seems reasonable. 
Stepan: What does a 100% loss preset compare to in a real-life scenario? Complete loss of connectivity (i.e. tunnel/metro, ....etc?)

Comment 3 by stkhapugin@chromium.org, Jul 5 

Exactly, I get this in Metro all the time. It's when you have connectivity but packets will pretty much always be dropped.

Comment 4 by mard...@chromium.org, Jul 5 

Thanks. 
Danyao: At what point does the back button become enabled? Upon receiving the first packet?

Comment 5 by danyao@chromium.org, Jul 5 

Yes, WKWebView updates the back/forward history after the headers are received. That's when the back button is enabled.

Comment 6 by gambard@chromium.org, Jul 18

Cc: gambard@chromium.org
This issue is roughly the same as issue 845403, but specific to NTP.
I think, to solve this issue, the NTP should be kept on screen until the navigation item is committed and the back button is enabled. I think this bug should become "keep the NTP on screen until item is committed".

I don't think this is specific to the new navigation, so the Proj-WKBackForwardList label can probably be removed.

Comment 7 by danyao@chromium.org, Jul 18

Labels: -Proj-WKBackForwardList
Owner: ----
Status: Available (was: Assigned)
Thanks for looking into this!
►

Sign in to add a comment