1645648 - Page load clears any edits made in the URL bar while the page was loading

Status: NEW

(Firefox :: Address Bar, defect, P3)

Description

[Paul]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

Initiate a page load from the URL bar (e.g. type "mozilla", press down to select an example page, and hit Enter), then immediately press Ctrl+L and begin editing the URL before the page loads.

Actual results:

When the page load finishes, any edits you were making to the URL are erased and replaced by the URL that has just loaded. This is of course far more obvious on slow connections.

Expected results:

Per all Firefox versions prior to 77 (as far back as I can remember), the browser honoured the user's edit: if the user had changed even one character, it would not clear the URL field when page load completed.

If the user changes their mind about the page, we should not throw away their work. Especially if for example the page is taking a long time to load, as the user may have made significant changes to the URL before page load completes or fails.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

I think we should just interrupt editing if a page load arrives, for security reasons. that's a dataloss but it's better than hiding the loaded page origin.

There's also bug 1629075, bug 1327297 and iirc another bug was filed recently for a similar problem, even if I can't find it atm.

Comment 3

[Cristian Comorasu, QA [:ccomorasu], Releae Desktop QA - Please contact [e-mail]]

Based on comment 2 I will update the bug status.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:adw, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 7

[Pierre Ossman]

(In reply to Paul from comment #0)

if the user had changed even one character, it would not clear the URL field when page load completed.

Just focus should be sufficient IMO. You can easily hit Ctrl+L with the intention to start typing, and before you've hit the first key the page loads and you get something screwy.

As an interim, could location bar focus be cleared on page load? At least you don't get the mixed version and it's clear that the page load aborted your typing. That might be what :mak suggested in comment #2.

Comment 9

[brainchild]

Just focus should be sufficient IMO. You can easily hit Ctrl+L with the intention to start typing, and before you've hit the first key the page loads and you get something screwy.

Are you suggesting that the content of the address bar should become locked, robust against any automatic change to reflect the loaded page, as soon as the bar gains focus, as an alternative to its becoming locked only after a character is inserted?

I myself might suggest that the locking should be deferred to after either an insertion event or a change in the selection range. Normally, the entire address is given the selection when the bar obtains focus. At this point, it may be too soon to lock the contente, as no clear indication has been given by the user that a change is intended. Use of an arrow key or other input to move the cursor, however, probably should trigger the content to become locked. A Ctrl+L stroke probably should be treated as a special case, as opposed to merely giving the focus to the address bar, as I believe the former but not the latter should trigger locking the content of the address bar.

Comment 11

[Michael F]

...[should]... the content of the address bar should become locked, robust against any automatic change to reflect the loaded page, as soon as the bar gains focus, as an alternative to its becoming locked only after a character is inserted?
I think so. That doesn't mean you can't track actual URL state outside of the address bar itself (say, in a variable), so that when the address bar loses focus it can reflect the actual URL state.
I myself might suggest that the locking should be deferred to after either an insertion event or a change in the selection range.
I don't think that's sufficient. You will live in constant fear of having created that insertion event at just the wrong moment -- just after the address bar populated. Then you will have to CTRL+L again to remove it and retype your search. If the address bar has focus, I don't think its contents should change.

Comment 12

[Michael F]

...[should]... the content of the address bar should become locked, robust against any automatic change to reflect the loaded page, as soon as the bar gains focus, as an alternative to its becoming locked only after a character is inserted?

I think so. That doesn't mean you can't track actual URL state outside of the address bar itself (say, in a variable), so that when the address bar loses focus it can reflect the actual URL state.

I myself might suggest that the locking should be deferred to after either an insertion event or a change in the selection range.

I don't think that's sufficient. You will live in constant fear of having created that insertion event at just the wrong moment -- just after the address bar populated. Then you will have to CTRL+L again to remove it and retype your search. If the address bar has focus, I don't think its contents should change.

Comment 13

[brainchild]

Reading this discussion again after several months, I feel more inclined to agree that once the address bar gains focus, the user effectively has entered into a transaction that should be protected against events not directly caused by user interaction yet otherwise causing its contents to be changed. This condition of protection should remain until the user might abort the transaction, by moving focus elsewhere, without having entered input.

Regarding when the address bar would become again open to being automatically updated with the address of a new page, I suggest considering the importance of the condition that the had not entered any new text. If the user begins entering text, but then moves elsewhere, in order to resolve the remainder of the text before submitting the complete address to be loaded, it would be incorrect, I think, for the earlier editing to be discarded

Note also depending on how the browser window manages its own state, there may be two separate cases to consider, for purposes of implementation changes, one in which a window is new enough that no page has yet been loaded into it, and the other in which a page has been loaded but a change to a new page is pending. Even though the cases might need to be implemented separately, the user experience should be unified, such that once a user initiates an interaction with the address bar, control over its contents would be granted exclusively to events of user input.

Comment 14

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 4 duplicates and 7 See Also bugs.
:adw, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.