255116 - Pressing Home or Shift+Home should close autocomplete

Status: RESOLVED FIXED

(Firefox :: Address Bar, defect)

Description

[Jesse Ruderman]

Steps to reproduce:
1. Ctrl+L.
2. Type part of a URL.
3. Down. (select first autocomplete entry)
4. Shift+Home. (select to beginning of line)
5. Shift+Delete. (cut)

Result: The autocomplete entry is removed.

Expected: The selection is placed on the clipboard (and deleted from the address
bar).

I hit this several times in a row before figuring out what was going on.

Comment 1

[Joerg]

thanks,
that helped me to delete some entries in my autocomplete-list

I think that is not a bug.

Comment 2

[Jesse Ruderman]

Joerg: can you elaborate? How did the ability to remove autocomplete entries
after editing them help?

Comment 3

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

The problem here is that Shift-Delete is an old DOS equivalent for "Cut" or
Ctrl+X. That shortcut is used to delete the entry and not cut the url to the
clipboard. Whether or not this is worth fixing is debatable IMO, as relatively
few use the old Shift+Del for cut.

Comment 4

[Jesse Ruderman]

Gavin, that's not the problem.  The problem is that Shift+Delete still deletes
the autocomplete entry *after* you perform selection/editing comments on the
autocompleted URL.

Comment 5

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

Reading comment 0, I think my interpretation is correct. The reporter expected
that "The selection is placed on the clipboard", where the selection is the
selected URL text. He was expecting it to be a regular "cut" of the URL, and got
a deleted autocomplete entry instead.

Comment 6

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

Err, didn't notice that you're the reporter. Nevermind my above comment then. It
still wasn't explained clearly.

Comment 7

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

(In reply to comment #4)
> Gavin, that's not the problem.  The problem is that Shift+Delete still deletes
> the autocomplete entry *after* you perform selection/editing comments on the
> autocompleted URL.

So, if I understand correctly, the most appropriate fix would be to make "Home"
act like "Left Arrow" (hide the popup)? That would make it impossible to select
text with the dropdown open, therefore avoiding the problem.

I can't see any other possible solution, since the "selection/editing" shortcut
you're using (Shift+Del) already has another function in our UI.

Comment 8

[Jesse Ruderman]

This bug is slowly driving me insane.

Comment 9

[Jesse Ruderman]

The solution I was thinking of was to change some hidden state when you start
editing so that Shift+Del (or, once bug 241774 is fixed, Del) acts on the text
rather than on the autocomplete entry.  But Gavin's solution, closing the
autocomplete dropdown when you start navigating/selecting, sounds more sane than
having hidden state, and is consistent with the current behavior for the left
arrow key.

Comment 10

[Mike Connor [:mconnor]]

So, this isn't a "blocker" per se, since its really really low-impact, and
unknown risk.  If you want to try a fix, the window is about a week and a half
really.

Comment 11

[Jesse Ruderman]

This might just be a simple fix in nsAutoCompleteController::HandleKeyNavigation
at
http://lxr.mozilla.org/mozilla/source/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp#424.


Untested pseudopatch:

  } else if (aKey == nsIAutoCompleteController::KEY_LEFT ||
-            aKey == nsIAutoCompleteController::KEY_RIGHT)
+            aKey == nsIAutoCompleteController::KEY_RIGHT ||
+            aKey == nsIAutoCompleteController::KEY_HOME)
  {

Comment 12

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

Attachment: patch

I've tested this on Windows, seems to work fine.

Comment 13

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

Oh, I forgot to change the comment just below the change in
nsAutocompleteController.cpp, I've changed it to:

// The user hit "Home" or the left or right arrow key

Comment 14

[Mike Connor [:mconnor]]

Comment on attachment 191792 [details] [diff] [review]
patch

please get some testing on Mac/Linux before getting approval.

Comment 15

[Adam Guthrie]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050806 Firefox/1.0+

Works on Linux, too. :)

Comment 16

[Jesse Ruderman]

On Mac, the Home key only affects the scroll position, and it doesn't do
anything in the address bar.  So the second hunk should probably get an #ifndef
XP_MACOSX.

Comment 17

[Jesse Ruderman]

Attachment: patch with ifndef

I haven't tested this yet; I'm rebuilding now to test on Mac.

Comment 18

[Jesse Ruderman]

Compiles and does the right thing on Mac (no difference in behavior from not
having the patch).

Comment 19

[Adam Guthrie]

*** Bug 298689 has been marked as a duplicate of this bug. ***

Comment 20

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

Checking in components/autocomplete/src/nsAutoCompleteController.cpp;
/cvsroot/mozilla/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp,v
 <--  nsAutoCompleteController.cpp
new revision: 1.32; previous revision: 1.31
done
Checking in content/widgets/autocomplete.xml;
/cvsroot/mozilla/toolkit/content/widgets/autocomplete.xml,v  <--  autocomplete.xml
new revision: 1.44; previous revision: 1.43
done

Comment 21

[Jesse Ruderman]

*** Bug 230677 has been marked as a duplicate of this bug. ***