1875550 - Address Bar contents get shifted leftwards (due to shield icon disappearing) when you enter edit mode, which makes it hard to do precise edits by clicking and deleting/editing

Status: RESOLVED DUPLICATE of bug 1906110

(Firefox :: Address Bar, defect, P3)

Description

[Daniel Holbert [:dholbert]]

STR:

1. Type or paste 1234567890 into your Address Bar and hit Enter to perform a search.
   Now: pretend you want to delete a character from the middle of your search term; let's say the 5 character. Here's what you do:
2. Click just to the right of "5" (and don't release the mouse-button yet)
3. "accidentally" move your mouse ever so slightly to the right (like 1px) and then release the button.
4. Press backspace, in an attempt to delete "5"

ACTUAL RESULTS:
The 5 character is still there, and 67 get deleted instead. Here's why:

• When you click, the address bar enters edit mode, and its whole contents shift leftwards (out from under your cursor) by ~2 character-widths.
• If you move your mouse at all as in step 4, then Firefox interprets this as you creating a selection from after the 5 to after the 7 (even though you barely moved your cursor).
• So when you hit backspace, Firefox deletes the selection after 5, instead of doing what you wanted.

EXPECTED RESULTS:
The text should not move around when I click.
No selection should be created.
At the end of the STR, the character 5 should have been backspaced.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: screencast of bug

Comment 2

[Daniel Holbert [:dholbert]]

Two scenarios that do match my expected-results, for comparison:

• Editing the actual URL (instead of a search term) in the address bar, e.g. when viewing this bugzilla page or any page where we're showing a full URL.
• Editing a search term in Google's own in-content searchbar (the one at the top of a search results page, rather than the bar in the Firefox UI)

Comment 3

[James Teow [:jteow]]

It's definitely a valid papercut.

When designing the persisted search terms feature, we originally showed the edit mode of the urlbar so users could know they could refine their search in the address bar. The added benefit was it avoided a choppy transition you're observing.

However, we went back and showed the original icons since hiding them prevented users from seeing the current state of their page (without knowing esoteric shortcuts on how to revert the URLbar) and would prevent helpful popovers from appearing.

The drawback is we have this awkward transition.

Couple options we could try:

• Not having the text move: This would create a lot of whitespace to the left of the text in edit mode
• Delaying the selection until after the transition to edit mode has finished. Additionally, what some browsers and applications do to get around this is to make it obvious that you have to click on the input box before you can edit it, so rather than showing the user an I-beam pointer (which implies you can immediately select the text), we could show the hand pointer.

Comment 4

[Daniel Holbert [:dholbert]]

(In reply to James Teow [:jteow] from comment #3)

Couple options we could try:

• Not having the text move: This would create a lot of whitespace to the left of the text in edit mode

This would be my preference; the fact that the text moves here is the papercut, as I perceive it. (The unexpected deletion that I described in comment 0 ACTUAL RESULTS is just one downstream result of that.)

• Delaying the selection until after the transition to edit mode has finished. Additionally, what some browsers and applications do to get around this is to make it obvious that you have to click on the input box before you can edit it, so rather than showing the user an I-beam pointer (which implies you can immediately select the text), we could show the hand pointer.

I'd lean against this route; it would go against the established user-interaction expectations for how the location bar works in Firefox (and perhaps most/all browsers). The location bar feels intuitively like a superpowered editable textbox; it's not a button or mostly-inactive element that only becomes editable when you click it. Also if we went this route, users could still easily end up with the similar unwanted deletion/edits as-described in comment 0, because they still didn't expect the text to shift out from under their cursor. (i.e. they might follow something like the same STR as in comment 0, and click a second time in step 2 because that's the hypothetical new requirement for editing (not noticing that the text moved out from under them), and then they'd end up with their cursor in an unexpected spot and delete the wrong character when they press backspace in step 4).

Comment 5

[James Teow [:jteow]]

I'm closing this because Bug 1919193 switched Persisted Search back to being visible in an invalid pageproxystate, so there should no longer be a shift when the search terms are selected.

Comment 6

[Daniel Holbert [:dholbert]]

Yup, I can confirm this isn't reproducible anymore. Two additional notes:
(1) "INVALID" implies the described behavior was never actually a bug, which isn't quite right -- FIXED/WORKSFORME would be a more-accurate resolution;

But, really:
(2) This actually became fixed before bug 1919193 landed. mozregression --find-fix finds an earlier fix range, with Nightly 2024-07-17 being the first good build (where "good" = the address bar contents still shift but not until after I release my mouse-button, so the STR don't end up inadvertently selecting/deleting unwanted text). Looking at the fix-range, I think this was in fact fixed by bug 1906110 (whose initial comment seems to be describing a version of the same issue that was being tracked here).

--> Duping to that bug.