Desktop (and More Likely Android) has the same behavior, where Reload reloads last committed NavigationEntry, instead of visible NavigationEntry. 

If we choose to change the behavior, then we should do that across all platforms, which will be a product-level decision.

Should the reload button change to stop on overscroll?

FYI, we weren't able to repro during scrub, so Srikanth will try later.

I can't reproduce this so far on M68 with/without UI refresh. Tried on GIN2g,3g networks. Pull to refresh reloads the webpage correctly. 

We had a similar issue in the past but was fixed. http://crbug/787795

I can only reproduce with the slim manager flag on (I should have been part of a finch experiment on my first device).
Eugene: it seems that this behavior is a regression introduced by the slim manager. So I don't know if it is something shared across all platform.

Here is a video, #slim-navigation-manager enabled, Chrome 68.0.3440.0, 2g-poor network.

srikanthg@: Can you confirm?

Deleted: PullToRefreshPoorNetwork.mov 2.0 MB

	PullToRefreshPoorNetwork.mov 2.0 MB View Download

I am removing the other platforms for now as I don't think this applies to them. Let me know if this is incorrect. Eugene, please feel free to route as needed.

Regarding the question in #4:
>> Should the reload button change to stop on overscroll?
No, I don't think it should change. From a muscle memory perspective, I think it would be quite confusing. 

Verified in:

App Version: 68.0.34440.0 canary
Devices: iPhone 7, iPhone 8, iPhone X
iOS Version: 10.3.3, 11.2.6 11.3.1

Issue is reproducible only with slim navigation manager flag ON. 

Re to comment #7. Per comment #1, I could reproduce this issue on Mac Desktop, and Android likely shares the same behavior (because the code is cross platform). By "same behavior" is mean that "reload reloads last committed navigation item".

Re to comment #6: Sounds like WK-based navigation manager implementation brings consistency across all platforms. 

Android, does not allow PullToAction gesture during the navigation. Mardini, should we just disable PullToAction if there is an in-progress navigation.

If we choose to make changes and match "expected result" in this bug, then I believe we should make the changes to all platforms, which is product-level decision.

Thanks for the clarification, Eugene. 

I personally think that the reload action should reload visible NavigationEntry. The users' intuition if they navigated away from page and are waiting for the new page to load and it's taking time, they'd hit reload again. They would not expect the previous page that they just left to be reloaded. Their intention is to try to get the current page faster. 

I wouldn't want to disable PullToAction during page load because the user might want to open a new tab or refresh still. Having it predictable and reliable is better.

I am unable to reproduce this on desktop though (maybe my network isn't bad enough).

Adding Nick and Ted to weigh in on the desired behavior.

I usually use this "slow" URL for testing: http://www.html-kit.com/tools/cookietester/
works best in incognito, which should not have any web caches.

Just wanted to clarify, is this pending any input from me?

mardini@, if you are still firm on your recommendation in comment #11, then we need to hear feedback from Android team. I believe that Chrome should be consistent on all platforms (and current behavior seems like consistent if slim-navigation-manager is enabled).

From a quick look, I think the difference on Android is that we don't provide a refresh affordance when loading a page.  As mentioned, we disable pull to refresh and our reload button is shown as a 'stop'.

For desktop, it seems like CTRL+r while a page is loading is simply ignored.

Are there any platform that show a reload option while a page is loading except for iOS?

On Mac Desktop Cmd+R reloads LastCommittedEntry. Tested with very slow http://www.html-kit.com/tools/cookietester/

Ahh...yes, that is indeed the same behavior on linux.  I mistakenly did right click open in new incognito tab and hit CTRL+r and expected it to go to the NTP, but in that case, it never had an NTP as the root navigation so it continually reloaded that link.

If I opened a new window first then navigated, I indeed see the same behavior on desktop.

But at least on Android, we don't have any visual affordance to reload, and our keyboard usage is so low, that I don't think we'll have much to say on this behavior.  If it changed, I don't think it would affect us much.

Thanks Ted! Adding checkboxes for other platforms. 

Charlie, this bug also affects Android and Desktop. Do you think we should change the behavior for NavigationController::Reload and reload Visible NavigationEntry, instead of LastCommitted NavigationEntry? tedchoc@ is ok with making changes on Android.

Personally, I think Reload should always reload the last committed entry and not the pending or visible entry.  That's consistent with our UX language where we change the reload icon to a stop icon during load, suggesting that reload is not an action to take related to the pending entry.  It's possible to re-issue the pending navigation by putting the focus in the omnibox and hitting enter again.

That said, this is perhaps more a question for UX folks.  I'm curious to get pkasting@'s opinion as well.

My initial instinct was strongly that reloading should reload the visible entry.  The more I think about what I'd expect this to do, the less certain I am of that instinct; reloading the last committed entry seems plausible.

I don't think the rationale in comment 21 holds.  Changing reload to stop during load is not really because reload doesn't make sense for the current page, but more because it's rare enough that we'd rather not pay an extra toolbar button just to allow it.

But that also doesn't mean that reloading the last committed entry is wrong.  I feel uncertain about what users would expect.  The comments above talk about "navigating away" and "the page the user just left", but when a load hasn't committed, you haven't left the previous page; the content area is still showing it.  So I'm not sure whether these arguments hold either.

Thanks, all. From my perspective, if the user took action to navigate away from a page, I don't feel that reloading the page they are trying to navigate away from is the expected behaviour. Even if they haven't left the page yet, they expressed the intention to do so. 

What's interesting is that on Mac FireFox reloads last committed entry and Safari reloads visible entry.

To throw my 2c in, I suspect the "right" thing to do is likely a heuristic based game.  If I click on a link and immediately hit reload, then I would think that the last committed entry is fine.  If I click on a link and it's been X time that the URL has shown the visible entry in the omnibox, I would think that reloading would likely reload the visible entry.

@pkasting, when do we issue a blank frame to clear out the old contents?  Does that only happen after we commit the navigation entry?  The presence of the old page definitely sends mixed messages if the omnibox shows one thing and the page the other.

My hand waving terrible idea would be that if the visible URL has been visible in the omnibox for a few seconds, then reloading that makes sense to me.

Buuuuuut...I don't really have a horse in this race, but I want to feel included too!!  I can definitely see the arguments of both sides.

We blank the frame only after the load commits.

The reason I think reloading the last committed entry could make sense is that it serves as a "no, I changed my mind, I really do want the current page" signal that overrides the load attempt.  Yes, the user expressed an intent to navigate away, but now they're expressing an intent to... what?

I think Ted is on to something with the idea that a reload attempt immediately after a navigation is maybe a "bail out" while a reload attempt later is a "why is this load so slow".  If that were the case, maybe five seconds would work?  OTOH, such a UI is unpredictable; there's no way to tell ahead of time exactly what reloading will do.  That makes me uncomfortable.

I still like PKs proposal from #22: reloading what is visible. It's more predictable to the user in my opinion. It may not always be what they want, but they should at least be able to reason about/follow what happened when they hit reload. 

Just to make sure we are on the same page, PK’s proposal is the same as my comment in #11, right?

(Retrying the conversation from the last few comments)

I didn't make a formal proposal, but I understood comment 27 to be asking for "reload last committed entry" (which is "what's visible" in the page content).

I think that's what I lean towards overall.  It's what Firefox does (see comment 24); it provides a way for the user to abort their navigation request; it's consistent with clicking twice on the stop/reload button in the toolbar; it makes more sense to me that something called "reload" would repeat what has been loaded, rather than something that hasn't loaded yet.

mardini@ stands by "reload visible entry", which is also a reasonable opinion.

This is not a #slim-navigation-manager specific issue. Reassigning to eugenebut@.

This is how Chrome works on every platform. PMs should make a product level decision on this (ideally consistent across all platforms).

Adding rpop@ for Desktop to weigh in. My view regarding this is summarized in #11 and #23

I'm inclined to agree with mardini in #11 that the user intent in this situation is to the troubleshoot the action they already took (navigate to a new page), so we should help load the new page. The fact that Chrome hasn't yet navigated isn't necessarily apparent to them.

+Tal for EM who is the PM most likely to have actual user research on slow networks/reload intent