1114013 - pressing END in autocomplete should work like right/home

Status: RESOLVED WONTFIX

(Toolkit :: Autocomplete, defect)

Description

[Magnus Melin [:mkmelin]]

Attachment: bugXXX_autocomplete_DOM_VK_END.patch

+++ This bug was initially created as a clone of Bug #1043310 +++

Pressing END in autocomplete should work like left/right/home. It used to be like this in the xpfe autocomplete too, and at least on windows/linux it does make sense.

xref bug 1043310 comment 27

This patch is on top of the patches for bug 1043310 and bug 1114011.

Comment 1

[Marco Bonardo [:mak]]

Comment on attachment 8539682 [details] [diff] [review]
bugXXX_autocomplete_DOM_VK_END.patch

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

Do you need this just to properly handle in-the-middle completion or are there other use-cases?

Cause this is going to hide the popup in some cases where we currently do not, it's minor cases, but if this is also covering a minor case, maybe we could handle it differently.

Comment 2

[Magnus Melin [:mkmelin]]

Its mainly a question of consistency. If I enter a value and hit right or home, the cursor moves to the end of the field and the value is completed (and not showing an uncapizalised or "foo >> foo bar" address). 

Without this patch the cursor just moves to the end and the final value is not used for END, while for RIGHT or HOME it moves to end and is completed.

Comment 3

[Marco Bonardo [:mak]]

Comment on attachment 8539682 [details] [diff] [review]
bugXXX_autocomplete_DOM_VK_END.patch

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

So, my problem here is that it might be common with features like autofill to type part of a url, press end to go to the end of the domain, and then keep typing based on results in the popup. This patch would end up hiding those results.

If we could limit the handling to in-the-middle complete results, or specific cases, it would help.

Comment 4

[Magnus Melin [:mkmelin]]

Comment on attachment 8539682 [details] [diff] [review]
bugXXX_autocomplete_DOM_VK_END.patch

Isn't that exactly what this patch achieves?

To take an example from the firefox urlbar. Let's say http://mozilla.org/ is in your history at top index. You go to the urlbar and type in "M" (capital m). 

Now, if you hit
 * right: you get http://mozilla.org/
 * HOME: you get http://mozilla.org/
 * END: you get http://Mozilla.org/ (with capital M)

I think END should do the same, and that is what this patch is about.

After you hit the key navigation you can the go on to type more, but you get the "correct" start.

Comment 5

[Marco Bonardo [:mak]]

My complain is not about the fact END completes (it already does with autofill, cause the right part is selected), my complain is about the fact it will close the suggestions popup, so the user cannot use the suggestions to keep filtering.
As I said
1. type "moz"
2. you get moz[illa.com]
3. END autofills to mozilla.com/
4. the user can check the suggestions and keep typing more to filter to a path

Comment 6

[Magnus Melin [:mkmelin]]

I see. Of course, the popup shows again if you type in more so I don't know if that's a big issue.

Comment 7

[Marco Bonardo [:mak]]

Comment on attachment 8539682 [details] [diff] [review]
bugXXX_autocomplete_DOM_VK_END.patch

I think I need third party advice here, cause my concern blocks me from proceeding with a decision, I might be wrong, but I need to compare with someone :)

My concern is that for the user it might be useful to see what's in the popup after pressing END, to be able to further filter down results, in certain cases like the awesomebar autofill, or when doing more complex text editing in autocomplete. But with this patch pressing END closes the popup.

The casing problem you suggest is interesting, but I'm not sure if we should handle END like the other navigation (loses casing) or the exact opposite (never lose user casing). But it's clearly a bug that RIGHT and END cause different results.
At least the patch would make the behavior consistent.

Could me I'm over-zealous or I'm putting my use-cases in the mouth of users.
I'm also not sure why END was not added at the beginning, I was not around and there might be very valid reasons that I am missing.

Gavin what do you think?

Eventually, we could do half-way, add an input attribute that states if END should be handled as a key navigation, and thunderbird could use that attribute where it wants. But that wouldn't add any consistency.

Comment 8

[:Gavin Sharp [email: [e-mail]]]

(In reply to Magnus Melin from comment #0)
> Pressing END in autocomplete should work like left/right/home. It used to be
> like this in the xpfe autocomplete too, and at least on windows/linux it
> does make sense.

This rationale is really only about "consistency" and is a little low on what the impact is for common use cases.

Marco's use case:
> it might be useful to see what's in the popup after pressing END, to be able to
> further filter down results

seems valid. Closing the popup seems less useful than leaving it open (this may be true about left/right/home too, though there may be good reasons why those should be different).

What are the use cases where it makes sense to close the popup?

Comment 9

[Magnus Melin [:mkmelin]]

What e.g. the urlbar does and what address autocomplete are pretty different wrt the data you get. In address autocomplete once you actually find the address you only have that, there's no sub-address parts to the full address - so in that case I think the current behavior of closing the popup is reasonable. 

Yes this bug was mostly about consistency, it's not that important so if you don't want it as default then I don't think we should bother with a pref behavior.

Right/home also closes the popup so maybe you in that case want to file a new bug about making those not close the popup.

Comment 10

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 8539682 [details] [diff] [review]
bugXXX_autocomplete_DOM_VK_END.patch

Sounds like we want WONTFIX with a followup to potentially fix the Right/home behaviour.