Closed Bug 1485746 Opened 2 years ago Closed 2 years ago

Cursor gets reset to start of address bar, when I alt-tab away from Firefox and back

Categories

(Firefox :: Address Bar, defect, P3)

All
Unspecified
defect

Tracking

()

VERIFIED FIXED
Firefox 63
Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 --- unaffected
firefox61 --- unaffected
firefox62 --- unaffected
firefox63 + verified
firefox64 --- verified

People

(Reporter: dholbert, Assigned: mak)

References

Details

(Keywords: regression)

Attachments

(2 files, 1 obsolete file)

STR:
 1. Type "a.b" into URL bar (or any string that involves some .suffix)
 2. Alt-tab to another window.
 3. Alt-tab back to Firefox.

EXPECTED RESULTS:
The cursor should be where I left it -- after "b", at the end of my entered text.

ACTUAL RESULTS:
The cursor has inexplicably been reset to the start of the address bar.


This is quite annoying if you're typing in an address, briefly alt-tab away to check your memory, and then alt-tab back and resume typing.  Your final characters end up at the beginning of the URL, because the cursor position was unexpectedly reset.

This is a recent regression in 63:
10:29.80 INFO: Last good revision: b4ac908007b9af47907b57891fc537201ef489a4
10:29.80 INFO: First bad revision: b6233f4d899c3da8143461b19201baf69e63595f
10:29.80 INFO: Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=b4ac908007b9af47907b57891fc537201ef489a4&tochange=b6233f4d899c3da8143461b19201baf69e63595f
(Wanted to tag mak for needinfo, but it looks like he's not accepting needinfo requests at the moment - hence, tagging Gijs as reviewer of regressing bug for the moment.)
Flags: needinfo?(gijskruitbosch+bugs)
Keywords: regression
It's because we set selectionStart = selectionEnd = 0 when the location bar is blurred, in formatValue: https://dxr.mozilla.org/mozilla-central/source/browser/base/content/urlbarBindings.xml#586 - and 'blur' fires when the window loses focus, apparently.

Off-hand, I can't think of a good way of fixing this. We could check if focus is somewhere else in the document and/or if our window is still active, but then we'd also need a handler that notices when the window regains focus that then checks if the url bar is receiving focus again, because otherwise the focus could just not go back to the url bar and the url could remain scrolled out of view.

I'm actually surprised this wasn't broken before...
Ugh, wrong mid-air button.
Flags: needinfo?(gijskruitbosch+bugs)
Keywords: regression
Here's me trying to type aaa.bbbb into my URL bar, with a brief alt-tab away and back partway through.

This bug makes me end up with "bbbaaa.b" in the url, rather than "aaa.bbbb"
The point here is that we don't want to end up with a situation where people can be misled into a situation where they end up with a formatted URL bar that isn't showing the host. formatValue() is only called when we stop editing the URL bar, and in that case the host should be visible. That's what the code is doing, and I don't see a particularly good way to disambiguate the STR from comment #0 from ones where the location bar *actually* loses focus, as it were. :-(
Priority: -- → P3
Maybe we could save the caret position on blur and then restore it on focus?  Some details to work out, obviously, but?
Tracked as a recent regression in 63, I was also able to repro this on Nightly63.
I reproduced it on Mac OS X 10.12 with Nightly (2018-08-23).
Hardware: Unspecified → All
... or just set scrollLeft to 0?  Seems to work...
Well now that I post that, I realize it's not perfect because when you switch back to Firefox, the text has scrolled back to the host and the caret isn't visible.  But, the caret is still actually where you left it at least, and when you start typing or moving with the arrow keys, the text jumps to where the caret is.
We used to only manipulate the scroll/cursor position when the value changed, prior to bug 1419391 landing. Is it not possible to do something similar again, instead of this workaround (which as comment #11 notes, still has some issues) ? Perhaps we can detect if the value has changed before making a decision, or if the blur is a result of "submission" (ie hitting enter / go / paste and go / drag+dropping a URL) in the url bar, or something? Would that be too fragile? Maybe Marco can clarify why he implemented it the way he did?

I'm out tomorrow (it's a public holiday here), so I won't have time to dive into this properly until Tuesday, but naively I would hope we could come up with a better fix. That said, we're doing the final merging to beta in just over a week, and I think we should land the patch Drew attached if we can't come up with something better before then (we can always uplift still-better fixes if we come up with them, something's better than nothing etc.).
Flags: needinfo?(mak77)
(In reply to :Gijs (he/him) from comment #12)
> Perhaps we can detect if the value has changed before
> making a decision, or if the blur is a result of "submission" (ie hitting
> enter / go / paste and go / drag+dropping a URL) in the url bar, or
> something? Would that be too fragile? Maybe Marco can clarify why he
> implemented it the way he did?

IIRC it was just matter of coherency, before the selection change was spread around in various call points, I wanted to consolidate it and it seemed to make sense and be safer to have a reliable behavior in general, so when the urlbar is blurred the host (or what is recognized as the host) is always visible.

Drew's approach sounds like a possibility, we already have some jumps of the text for RTL... As you suggested we could also skip the selection set in certain cases. I'll do some testing and see.
I think in the end I will just restore the previous code touching the selection on change, it's not strictly necessary to keep it.
I must note the problem Drew pointed out in comment 11 is likely to already exist for RTL where we indeed set scrollLeft regardless of the cursor position... But that's likely an edge case anyway and it has more implications with the security fix.
Assignee: nobody → mak77
Status: NEW → ASSIGNED
Flags: needinfo?(mak77)
Blocks: 1482557
This restores the previous behavior where we set the selection only when setting a new different value
Comment on attachment 9004837 [details]
Bug 1485746 - Cursor gets reset to start of address bar on window switch.

Drew Willcoxon :adw has approved the revision.
Attachment #9004837 - Flags: review+
Attachment #9003947 - Attachment is obsolete: true
Pushed by mak77@bonardo.net:
https://hg.mozilla.org/integration/autoland/rev/621979b26f69
Cursor gets reset to start of address bar on window switch. r=adw
Blocks: 1486058
https://hg.mozilla.org/mozilla-central/rev/621979b26f69
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 63
I verified this issue on Mac OS X 10.12, Windows 10 x64 and Ubuntu 16.04 with FF Beta 63.0b3  and FF Nightly 64.0a1(2018-09-05) and I can confirm the fix.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
Depends on: 1489402
Depends on: 1496158
No longer depends on: 1496158
Regressions: 1496158
You need to log in before you can comment on or make changes to this bug.