Closed Bug 1674951 Opened 4 years ago Closed 2 years ago

Location bar keyboard focus unstable when web site loading is in a loop

Categories

(Firefox :: Address Bar, defect, P3)

Firefox 81
defect
Points:
3

Tracking

()

RESOLVED FIXED
101 Branch
Tracking Status
firefox101 --- fixed

People

(Reporter: lisa.dusseault, Assigned: daisuke)

References

Details

(Keywords: papercut)

Attachments

(2 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:81.0) Gecko/20100101 Firefox/81.0

Steps to reproduce:

In local development, I have a state where due to a bug in my web server code, there's a loop between two web pages (an error page and the home page). So that's my problem. But in the meantime, I can't use the Firefox location bar to go to a URL that isn't reloading the error page and the home page every second. Every time I try to type in the 'login' part at the end of the URL to get out of the loop I'm interrupted by having the keyboard focus go to the beginning of the URL. I try to use keyboard to get to the end of the URL but as soon as the page reloads it goes back to the beginning of the URL so I can't fix the URL to escape the loop.

Now, granted, this isn't inescapable. I can kill the tab and start a new tab and NOT go to the URL that causes the URL loading bug. I can use the mouse, which for some reason doesn't suffer from the focus problem (but I normally don't use the mouse, I'm a very keyboard-oriented user).

The reason I'm reporting this and crossing my fingers that it's fixed is that I have other keyboard-only issues using the Firefox location bar, which are harder to reproduce. There's some other issue where I open a tab (keyboard only) and type in a URL or some search terms (keyboard only) and then I get stuck in the dropdown search results without being able to get back to the typing focus (unless I use a mouse) Maybe some attention to mouseless focus on the location bar would fix those issues that I have more trouble nailing down exactly how to reproduce!

Actual results:

While trying to edit the URL, since the web page is reloading while I'm trying to enter the correct URL, focus jumps to the beginning of the URL even though I'm trying to type at the end of the URL.

Expected results:

THe keyboard focus should have remained at the end of the URL since I put the keyboard focus there.

Hi lisa.dusseault,

Reproduced this issue by continuously reloading a site and also trying to edit the URL in the meantime and the focus jumps to the beginning of the URL instead of remaining at the end where I started editing it. This is quite an uncommon scenario so marking it as an enhancement unless developers consider it otherwise.
Thanks for the report!

Status: UNCONFIRMED → NEW
Type: defect → enhancement
Component: Untriaged → Address Bar
Ever confirmed: true

Timea, which version did you reproduce the bug on? Could you please check if it happens in Nightly? We had another user saying he could not reproduce this in Nightly.

Flags: needinfo?(timea.babos)

I can reproduce this easily on the latest Nightly 84.0a1 (2020-11-10) (64-bit) on Windows 10 x64.
Steps to reproduce (also attached a screen-recording for convenience):

  1. Load any heavy content site, ex: https://edition.cnn.com/2020/11/11/asia/hong-kong-lawmakers-unseated-china-intl-hnk/index.html
  2. Focus the address bar and have the cursor positioned at the end of the url
  3. Start typing in anything and press F5 in the same time

Observed behavior:
The cursor is placed at the beginning of the URL when the page is reloaded.

Flags: needinfo?(timea.babos)
Severity: -- → S3
Keywords: papercut
Priority: -- → P3
Type: enhancement → defect
Points: --- → 3
Assignee: nobody → daisuke
Status: NEW → ASSIGNED
Attachment #9272055 - Attachment description: Bug 1674951: Set the caret position to the end the URL after loading. → Bug 1674951: Update the caret position after loading page.
Pushed by dakatsuka.birchill@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/d26291505524
Update the caret position after loading page. r=adw
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 101 Branch
Regressed by: 1767053
No longer regressed by: 1767053
Regressions: 1767053
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: