Closed Bug 719890 Opened 12 years ago Closed 8 years ago

Pressing "backspace" in the location bar does not delete the last character typed, if inline autocomplete is active

Categories

(Firefox :: Address Bar, defect)

Product:
Firefox
Component:
Address Bar
Version:
12 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: mbrubeck, Unassigned)

References

Details

(Keywords: regression, ux-consistency, Whiteboard: [inline-autocomplete:enhancement])

Attachments

(2 files, 1 obsolete file)

this patch deletes the last character when backspace is used and autocomplete is on
1022 bytes, patch
Unfocused
: review-
Details | Diff | Splinter Review
This patch removes the last character while retaining the normal behaviour of backspace
2.06 KB, patch
Details | Diff | Splinter Review 
Steps to reproduce:

1. Focus the location bar.
2. Press the "g" key.
3. Press the "o" key.
4. Press the backspace key.

Expected results: "g" is in the location bar.
Actual results: "go" is in the location bar.

This happens because of bug 566489.  After step 3, the location bar contains an auto-completed URL like "go[oogle.com]" (the "oogle.com" is selected).  Pressing backspace deletes only the selected part, not including the last character typed.

I'm not sure of the best thing to do here.  The current behavior makes perfect sense if you are looking at the URL bar and see what is happening, but it wreaks havoc whenever I type fast and try to correct mistakes as I go.  It also introduces a mode error, where pressing backspace produces different results depending on whether the browser has just found an auto-complete suggestion.

This has already caused me to enter incorrect URLs twice in the last hour, and it was confusing to figure out what happened.  It's possible that this should be WONTFIX, but I'm hoping someone can come up with a creative solution to this problem.

Found in mozilla-central nightly Mozilla/5.0 (X11; Linux x86_64; rv:12.0a1) Gecko/20120120 Firefox/12.0a1.
I don't know if this can be considered a regression or not. Your browser "typed" additional characters into the url bar for you - the last set of characters are deleted when you press backspace. With inline autocomplete, this seems like 'expected behavior'. However, I just updated to this nightly, perhaps it will cause me grief as well:)
> I'm not sure of the best thing to do here.

Delete both the auto-complete suggestion and the "o"?

In general, I don't think the auto-complete suggestion should not be highlighted.  For example, if I ctrl+c, it copies "ogle.com" to the clipboard, which doesn't make much sense.

FWIW, Chrome on Linux has the same behavior as we currently have, both with <backspace> and <ctrl+c>.
> Your browser "typed" additional characters into the url bar for you - the last set of characters 
> are deleted when you press backspace. With inline autocomplete, this seems like 'expected 
> behavior'.

Consider how your smartphone's keyboard works.  It might suggest or even "type" additional characters for you, but backspace means "undo the last thing *I* typed"!
>  I don't think the auto-complete suggestion should not be highlighted.

I should say, I don't think the suggestion should be *selected*.  It should of course be set off visually somehow, perhaps with something which makes it look like it's selected.
(In reply to Justin Lebar [:jlebar] from comment #3)
> > Your browser "typed" additional characters into the url bar for you - the last set of characters 
> > are deleted when you press backspace. With inline autocomplete, this seems like 'expected 
> > behavior'.
> 
> Consider how your smartphone's keyboard works.  It might suggest or even
> "type" additional characters for you, but backspace means "undo the last
> thing *I* typed"!

But if Backspace deletes the last pressed character and not the text selected, then how are you going to go to a web address which goes like this :
  "facebook.com/rob" , then suppose you already have visited "facebook.com/robert" and your browser auto comlpetes to "facebook.com/robert" (with "ert" selected) as soon as you complete typing "facebook.com/rob"
Now if you press backspace and want to undo the last typed character , then url left on the address bar would be "facebook.com/ro" and you would again have to press 'b' to go to "facebook.com/rob" and again Inline auto complete would auto complete to "facebook.com/robert" ("ert" selected) , and the process continues.

Hope it is all clear (what I tried to explain)

> In general, I don't think the auto-complete suggestion should not be           > highlighted.  For example, if I ctrl+c, it copies "ogle.com" to the clipboard, > which doesn't make much sense.

About the copy issue, I think a new bug should be filed, and we should not allow anything to be copied, as the text selection is done by browser and is meant for something else and not copying
(In reply to scrapmachines from comment #6)
> But if Backspace deletes the last pressed character and not the text
> selected, then how are you going to go to a web address which goes like this
> :
>   "facebook.com/rob" , then suppose you already have visited
> "facebook.com/robert" and your browser auto comlpetes to
> "facebook.com/robert" (with "ert" selected) as soon as you complete typing
> "facebook.com/rob"
> Now if you press backspace and want to undo the last typed character , then
> url left on the address bar would be "facebook.com/ro" and you would again
> have to press 'b' to go to "facebook.com/rob" and again Inline auto complete
> would auto complete to "facebook.com/robert" ("ert" selected) , and the
> process continues.
> 
> Hope it is all clear (what I tried to explain)

Inline autocomplete only adds a feature. In such case, the dropdown is still there for other matches. Moreover, it should only complete to "robert" if that link has been significantly more visited. When the visit frequency is about the same, I think we should always complete to the shortest full match when overlapping occurs. It looks to me like more logical UI to put your cursor at the end of the autocompleted text and start typing the rest of the URL than trying to do it the other way round.

In your use case, the user can also press delete instead of backspace. which only deletes the highlighted text.
(In reply to Tim from comment #7)
> Inline autocomplete only adds a feature. In such case, the dropdown is still
> there for other matches. Moreover, it should only complete to "robert" if
> that link has been significantly more visited. When the visit frequency is
> about the same, I think we should always complete to the shortest full match
> when overlapping occurs. It looks to me like more logical UI to put your
> cursor at the end of the autocompleted text and start typing the rest of the
> URL than trying to do it the other way round.

In my use case, I meant "facebook.com/rob" to be a totally new url, never ever visited before, and the user wants to visit it since he got this url from a friend or anywhere else.

> In your use case, the user can also press delete instead of backspace. which
> only deletes the highlighted text.

Yes, that can be a solution, but then how will a normal user come to know of it?, that to only delete the selected text he has to press Delete, and to remove the selected text as well as last entered character, press Backspace.
I think it would be less discoverable and may be confusing.
> I think [backspace deletes last typed char, delete deletes highlighted section] would be less 
> discoverable and may be confusing [than what we currently have].

Yes, that's the trade-off, I think.
I think the deletion needs to include the character just typed as well as the autocomplete part.  

In regards to Comment 2 and Ctrl-C.  Its not a huge usability regression since prior to implementation Ctrl-C did nothing, since nothing would have been selected.  Perhaps the fix is to again have nothing actually selected, but just set the autocomplete off visually.

On Comment 6, there needs to be an override for this edge case: wishing facebook.com/rob instead of the chosen facebook.com/robert.  The space bar seems like a fairly intuitive choice for anyone who has had to override the autocomplete features while texting on a phone.
But pressing space is not the first option in our mind while pressing space, I think that would be a little hard to understand.
FWIW, if I'm not wrong this issue is not due to the new inline implementation, but goes back to the concept itself of inline autocomplete, it was already valid for the old implementation, right?
It's hard to figure what's the scope of the user, either to tell "no please don't autocomplete" or "I mistyped this", both things we may do, delete the selection or delete the selection plus one char, would make the other expected behavior worse.
Peanut gallery suggestion:

* don't use an actual selection for the autocompleted part of the URL, and render
  it differently from a normal selection

* have Backspace delete the previous character and not the autocompleted part

* hold down Option (or whatever it is for other platforms) to hide the autocompleted
  part, such that pressing Option+Enter will open the URL without autocompletion

The Option thing would be similar to how it works for overriding the "Switch to tab" items in the awesomebar dropdown.
This also happens when you press Down to select an item from the awesomebar suggestions and press Backspace to delete the last character.  Instead it just highlights the character (because it has autocompleted it again).  Same if you press Ctrl+Backspace (or Option+Delete on mac), the deleted word is reinserted and highlighted.
This rubs my muscle memory backwards, not going to relearn quickly, I guess. Having three different profiles on different channels isn't going to help.

I think in terms of behavior change, we should only compare to the default awesomebar, and not an optional behavior.

One think I know about my typing habits is that I actually recognize typos while typing blindly, and know how many backspaces that needs to correct. Fast and sluggish typing on my part. Given that there's not a lot of visual feedback going into that 'autocorrection' in my typing habit, dropping a backspace for the completion is pretty disruptive. No idea how common that problem is for people, though.
comment 15 is bug 719888, the reason that happens is largely different and a bug we can fix.

The best suggestion here is to have a different type of autocompletion that doesn't modify the typed text, instead shows a greyed out suggestion. Though that may take lot of time to be implemented.

We may try to implement the backspace-removes-last-typed-char, and see how it feels, actually it should not cause another autoFill, if we properly fix bug 721225, that is caused by trimURL.
Whiteboard: [inline-autocomplete:uiwanted]
Keywords: uiwanted
(In reply to Cameron McCormack (:heycam) from comment #14)
> Peanut gallery suggestion:
> 
> * don't use an actual selection for the autocompleted part of the URL, and
> render
>   it differently from a normal selection
> 
> * have Backspace delete the previous character and not the autocompleted part

While this is a good suggestion in itself, we probably can't go against how this works in other browsers and other autocomplete implementations. Backspace deletes the selected text, and anything more complex than that will probably be more confusing than helpful.
Keywords: uiwanted
(In reply to Alex Limi (:limi) — Firefox UX Team from comment #18)
> While this is a good suggestion in itself, we probably can't go against how
> this works in other browsers and other autocomplete implementations.
> Backspace deletes the selected text, and anything more complex than that
> will probably be more confusing than helpful.

We can't? Is this Firefox or is this the we-have-to-copy-others-browser?  If we come up with something better, then do it. We are not Chrome/Opera/... . If I wanted to use another browser, I'd use it.

FWIW: this bug is one of the reasons I turned off autocomplete. Yes, it's *that* annoying.

P.S. Sorry for the rant, I know this isn't what Bugzilla is for, but I just needed to say this. You can be influenced by other browsers and copy good behaviour, but you are saying yourself that it's a good suggestion. Being different isn't a valid reason to block something. Daring to be different is what makes Firefox better.
You can't have this both ways, I think.  Either we're implementing something which works just like other implementations, and we should judge all relevant bugs on that criterion (e.g. bug 720258), or we're not, in which case we should at least hear the complaint that this makes typing without looking at the screen impossible.
Whiteboard: [inline-autocomplete:uiwanted] → [inline-autocomplete:enhancement]
Could this be implemented as a configuration option so that users could choose which way to do it? 

Of course the default could be the one option that everybody else uses, but I'd really like both autocomplete and backspace deleting the last thing I typed, and I now I can't find a configuration option for that.

This annoys me a lot - also in the other browsers, but Firefox did work as I wanted, this far.
Comment on attachment 657779 [details] [diff] [review]
this patch deletes the last character when backspace is used and autocomplete is on

(Duplicate patch, marking just this one obsolete.)
Attachment #657779 - Attachment is obsolete: true
Attachment #657779 - Flags: review?(mak77)
Comment on attachment 657774 [details] [diff] [review]
this patch deletes the last character when backspace is used and autocomplete is on

Review of attachment 657774 [details] [diff] [review]:
-----------------------------------------------------------------

This works for when you're normally typing and the highlighted part is the auto-completed text. However, if you've the cursor to somewhere in the middle of the text that you've typed, then hit backspace, it still removes all text after the cursor - in that case it should only remove the character to the left of the cursor (ie, normal behaviour).
Attachment #657774 - Flags: review?(bmcbride) → review-
Comment on attachment 657774 [details] [diff] [review]
this patch deletes the last character when backspace is used and autocomplete is on

Really need a UX final call on this, before any further proposed patches. 

Do we fix this as suggested, or WONTFIX the bug?
Attachment #657774 - Flags: ui-review?(ux-review)
Normal function of backspace has been restored in this patch. I'm new to firefox development so can you tell if this approach is correct or is there another better approach?
Attachment #658578 - Flags: review?(bmcbride)
Attachment #657774 - Flags: ui-review?(ux-review)
Comment on attachment 658578 [details] [diff] [review]
This patch removes the last character while retaining the normal behaviour of backspace

Still waiting on UX input here... clearing my review until that happens.
Attachment #658578 - Flags: review?(bmcbride) → ui-review?(ux-review)
Depends on: 719888
Comment on attachment 658578 [details] [diff] [review]
This patch removes the last character while retaining the normal behaviour of backspace

ux-review review alias seemingly hasn't been usefully used in years, so clearing this. 

And it's been so long that this bug needs re-looked at from scratch anyway - both from a UX perspective and a code perspective.
Attachment #658578 - Flags: ui-review?(ux-review)
I did a little survey of this behaviour in various browsers.

In all browser, I found that pressing backspace doesn’t delete the last character typed. It merely deletes the rest of the URL that has been autocompleted in the URL bar.

On Google Chrome, you can turn this behaviour off by going to Settings > Privacy > uncheck “Use a prediction service to help complete searches and URLs typed in the address bar […]”. Finally, clear your browsing history.
I say we WONTFIX this.
Reasons:
- This is the default behavior across browsers, so many people will be used to it. (Chrome slightly more focuses on favoring search terms over URLs, but Edge seams completely in line with our behavior. )
- We focus on helping people get back to content they already visited, which autocomplete is great for. And even if not 100% positive, running into the mentioned troubles will help you learn about how to easier get back to the content you want to see. (As you might realize that there is such a thing as auto-complete.)
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
(In reply to Markus Jaritz [:maritz] (UX) from comment #32)
> I say we WONTFIX this.
> Reasons:
> - This is the default behavior across browsers, so many people will be used
> to it. (Chrome slightly more focuses on favoring search terms over URLs, but
> Edge seams completely in line with our behavior. )
> - We focus on helping people get back to content they already visited, which
> autocomplete is great for. And even if not 100% positive, running into the
> mentioned troubles will help you learn about how to easier get back to the
> content you want to see. (As you might realize that there is such a thing as
> auto-complete.)

There are definitely benefits to matching expected autocomplete behavior. It should also be noted that the visual queues present in this scenario backup this behavior: We remove the text cursor which usually indicates that backspace will go back one character. We then use the text selection highlight on the autocompleted result. This indicates the characters that will be affected if you hit backspace.

Also there are reasons for why it works the way it does beyond just matching existing autocomplete behaviors. The reason we select the predictive part is because we are optimizing for the case where Firefox is wrong. It should be easy for the user to quickly remove the part that was added if it is not what they want. Thus preserving their original search term.

A slightly contrived example:

- I want to search for facebook and not go to facebook.com
- I type "facebook" and Firefox completes it to "facebook.com"
- I hit backspace once and now I can hit enter to search for facebook

If we also went back one character I would be back at "faceboo" and have to type k again. Making it easy to get into an infinite loop of autocomplete.

In other words: it's a trade-off between easily removing the predictive part and having to double-backspace to fix a typo.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: