1110297 - When stopping page load and attempting to reload, the URL disappears from the bar and no reload is attempted

Status: NEW

(Firefox :: Address Bar, defect, P3)

Description

[Brian Grinstead [:bgrins]]

STR:
Open a new tab
Enter a URL to a page that takes a while to load, like: http://briangrinstead.com/files/sleepy.php
Stop page load before it finishes by pressing the stop button or pressing ESC
Try to reload the page by pressing the reload button or pressing ctrl+r

Expected
The page is reloaded and the URL in the url bar

Actual
The URL disappears from the URL bar and the page doesn't attempt to reload

Comment 1

[arni2033]

See also bug 798249

Comment 4

[Marco Bonardo [:mak]]

Our suspect is that this may have been caused by loading about:blank before the actual load, I think this has been changed in the last years so we don't do that anymore. We are having difficulties reproducing the problem (we also need a new test case).
Gijs am I correct that we don't load about:blank anymore in any case?

Comment 5

[Marco Bonardo [:mak]]

James will try to make a test case or reproduce this bug.

Comment 6

[:Gijs (he/him)]

(In reply to Marco Bonardo [:mak] from comment #4)

Our suspect is that this may have been caused by loading about:blank before the actual load, I think this has been changed in the last years so we don't do that anymore. We are having difficulties reproducing the problem (we also need a new test case).
Gijs am I correct that we don't load about:blank anymore in any case?

We try to avoid it but I think there are still a lot of cases where it would still be loaded - almost any access of the docshell/document will do so. When I tried to get rid of it more completely it broke a bunch of stuff, because it e.g. causes docShell.currentURI to return null, which made a lot of things sad. Perhaps now that we're in more of a fission world and use browsing context info in more places, this doesn't happen as much? I don't know if I still have the patches somewhere.

Anyway, this means it is likely harder to reproduce, but not impossible - it will likely relate to whether the server accepts the TCP connection immediately or only after a while (ie how good the internet connection is) and/or how quickly we get response headers (which will trip OnStartRequest or OnLocationChange, I forget which). Does that help?

Comment 7

[Emily Bowman]

It doesn't happen as often now, but it does still happen if a link is opened in a new window/tab instead of the current one and is too slow to connect. If you're quick enough on the draw, you can replicate it by opening an email and immediately pressing escape to cancel; it'll revert to about:blank. Or send yourself an email with a link to a nonexistent or incredibly slow-to-connect site, perhaps. (Don't remember any offhand, will update next time I find a good test case.) I primarily run across it now when there's a hiccup in my DNS or internet in general, before the NIC goes into offline mode; when it finally times out, the URI will be blanked.

It does seem like as soon as the TCP or HTTPS handshake is completed, it will no longer revert, even if it's still waiting for the first headers.

Comment 8

[James Teow [:jteow]]

(In reply to Marco Bonardo [:mak] from comment #5)

James will try to make a test case or reproduce this bug.

Marco, for a completely blank page, I wasn't able to completely reproduce this bug.

What I did was throttle my network to a slow connection, entered a url, started loading the page, and then stopped it quickly before the url bar transitioned from a search icon into a shield/lock. Here are my observations of stopping the browser depending on the state of the tab I was using:

• If my tab was was a blank page, the url bar has the url of the page but the reload button is disabled

• If my tab uses Firefox Home as the blank page, the url remains in the url bar but reloading just reloads Firefox Home.

• If my tab was on an existing website, the url bar turns back into the url that I was viewing before

I did the same test without throttling and loaded a page I know that takes a second or to give a response and it still didn't act abnormal.

The only time I was able to fully recreate a situation like the original bug submitter was to click on a link as the new tab and stop it quickly similar to what Emily suggested. Of note, that's stopping the tab before the url shows up in the url bar, so that's not the same as having seen the url in the url bar and seeing it disappear upon stopping.

Comment 9

[James Teow [:jteow]]

Actually Marco I was able to reproduce it although the reasoning behind why the tab does it is a mystery because it's not consistent among blank tabs on my browser.

Some blank tabs act normal, but some are doing what Emily and the original bug submitter mentioned which is if you early stop the load, it clears the url bar. What's interesting is the behaviour remains consistent if you move to another about:blank page in that same tab. Like say I go to another website in that tab, and then go to about:blank again, it'll clear the url bar if I stop the load before I see the icons change in the url bar.

Edit: Upon further testing, I realize the inconsistency I'm seeing is because there is a subtle difference between tabs when they can go back to a previous url and when they are the first page. If they can go back and you cancel the page load fast enough, the url bar will go back to a state of the previous page (including a blank url) due to https://searchfox.org/mozilla-central/source/browser/base/content/tabbrowser.js#6567 where this.mTab.isEmpty is false. And so unfortunately that doesn't help re-create the precise problem outlined in this bug that's using a new tab with no history.

Comment 10

[James Teow [:jteow]]

I found a blog entry by Sean Shadmand where he provides links to a slow response server he set up: http://www.seanshadmand.com/2012/06/21/fake-response-server-slow-response-time-generator/

I did some basic tests with it: http://www.fakeresponse.com/

When I create a new Blank Page tab and manually enter the url, stopping the load doesn't eliminate the url from the url bar.

When I click on a link to the slow server using "Open a New Tab", the new tab contains the url, and stopping the load doesn't eliminate the url from the url bar.

When I select the link to the slower server using "Open a New Window", the window loads without a url and stopping the load results in the url bar remaining blank. The same thing happens when clicking on an anchor tag containing target="_blank". That point might be relevant since target="_blank" can result in opening in a new tab rather than a new window.

Comment 11

[Marco Bonardo [:mak]]

Great findings James.
Is the code differentiating the case where the user typed a url, from the case where you are visiting a url starting from a link? In the former case I'd expect the user typed text to not be lost.
So we're restoring the urlbar to the previous state, that may also be blank. That seems mostly correct, I wonder if not doing that may open us to spoofing attempts where we'd leave a previous url on a partially loaded page. That's likely not critical if the user themselves typed the loading string, so we could differentiate based on that, but we are not tracking user typed string properly (as discussed in https://phabricator.services.mozilla.com/D99022#3230980, having userTypedValue doesn't really represent whether the value was actually user typed)
I'm not sure whether there's a super clean solution here, if we decide to leave a pending url in the urlbar, we should somehow make it clear it's not fully loaded yet... maybe fixing bug 1577539 would be a good first step to differentiate not loaded urls.
If instead we just want to fix the refresh button, we risk to put the ui in a not consistent state (refresh and the urlbar value won't match).

This seems another one of those cases where we'd really like to show both a pending and current url values...

I think we could start fixing bug 1577539, making easier to track if the userTypedValue was effectively user typed, and maybe don't restore old url if we have a user typed value. That would still not fully address this but it would address another part of it. The remaining part couldn't be done unless we find how to clearly indicate that the currently shown URL may be a pending load rather than the currently loaded page, for security reasons.
Does this match with your findings?

Comment 12

[James Teow [:jteow]]

Hi Marco,

Is the code differentiating the case where the user typed a url, from the case where you are visiting a url starting from a link?

Hmm could I get more clarification for this question? Basically I've been unable to re-create the precise situation the original bug poster explained of opening a fresh new tab, pasting a url, and the slow url disappearing after stoping it. From a no-history Blank Page, when I type a url, submit it, and halt it before it loads won't lose the typed text. Likewise a no-history new Firefox Home (Default) page with a user typed url retains the url.

The only time I can replicate something similar is if I open a link in a New Window with the slow url and stop it, and that's because the url doesn't show up in the first place even in the interim state. Likewise if the link has target="_blank".

To figure out why, I looked into what you mentioned in your Phabricator comment regarding userTypedValue, which gets modified by the code quite a bit. In tabbrowser.js, there's a block of code that sets the browser's userTypedValue to the uri before further down the process calling setURI. However, userTypedValue doesn't get modified if skipLoad is true.

This happens when the user clicks on a link that has target=_blank, as the Javascript code adds skipLoad as true as a final parameter in a function called in the return statement.

Opening a link in a new window has a similar visual behavior not because of skipLoad but because when a new window is initialized, it subscribes to a progress listener and will only call setURI in a different path to convert the blank uri to something after an onLocationChange event.

In contrast, the behavior of using a context menu to open a link or keyboard shortcuts while clicking a link (for example to open a link as the new focused tab) shows the URI in the interim state because they omit skipLoad while also eventually calling setURI.

---

This might be tangential but I see UrlBarInput.js has this.valueIsTyped which might be a way of tracking the state of user typing. It's initialized in a new tab/window as false, and only turns true under the following circumstances:

• A user types/pastes a value in the input bar

• A user switches the search mode, for example setting the search to do a one-time search

• valid = false in setURI: I suppose if valid is false, it must be the case that the uri was entered by a user? However, one issue is we could have manually modified the url to a valid url which would set this.valueIsTyped to true via the keyboard event in bullet point one, swap to a different tab, and then when you return to the tab, setURI will set the state of this.valueIsTyped as false.

this.valueIsTyped is set to false when setValue is called, which can happen a lot because of a number of callers, such as setURI(conditional), _autofillValue, setValueFromResult, onFirstResult ... if I had to guess, I this.valueIsTyped is pretty strict about human typing.

But one "drawback" is pressing enter to commit to loading a uri while this.valueIsTyped is true will often cause the variable to turn false . I'm assuming it's because pressing enter from the Urlbar executes the heuristic result, which in turn may modify the user typed text?

---

As for pending and current url values... personally I think showing two urls would be confusing and that reverting back to the current url like it does now makes perfect sense and I certainly wouldn't want to touch it, even in the case of the tab with history blank page inconsistency that I noted (which is super edge case).

To your point of potentially trying to retain user entered values on a page with history, do you think either modifying this.valueIsTyped or creating another type that has looser rules than it could work?

Comment 13

[James Teow [:jteow]]

Marco, I'm wondering if we should close this bug and create another version with similar but with different reproduce-able steps?

As mentioned, I haven't been able to reproduce the full bug the original bug author encountered. Yes, pressing Refresh on a New Tab doesn't reload the temp url in the bar (and in the case of a Blank Page, it's disabled altogether), but I would imagine we don't feel comfortable changing the behavior of Refresh. The main annoyance of the bug seemed to have been human entered urls getting cleared from the url bar on a New Tab when the page is stopped early, but it works fine for me.

There are cases when url's get cleared, but they are seemingly unrelated to the steps the bug author wrote.

For the case where you're on an tab with history, paste a url, try loading, and then stop it before it loads, causing the url to revert back to the url of the page it's actually on, it's arguable whether we should mess with that.

For the bug that Emily Bowman mentions where clicking on a link to open new tabs/windows can result in blank urls, that seems like it has more to do with the fact that sometimes the new tab/window gets loaded without a url in the url bar, and the url bar doesn't get populated until the link is either partially loaded or fully timed out. The set of steps to reproduce that bug seems like it opens up a broader discussion of whether the url of that page you're trying to load in a New Window (or New Tab/Window generated from target: _blank) should always appear in the url bar or if there are valid reasons (security related perhaps?) why we omit it.

Comment 14

[Marco Bonardo [:mak]]

So we have identified 3 potential causes of the problem, that should be filed in new separate bugs, then we'd close this bug as incomplete because as-is this bug is not actionable.