408723 - always use the input field's value when pressing enter in an autocomplete field (e.g. URL bar)

Status: VERIFIED FIXED

(Toolkit :: UI Widgets, defect, P2)

Description

[Daniel Holbert [:dholbert]]

I've run into this bug a lot lately.  

Basically, if the cursor happens to be hovering over the AwesomeBar dropdown area when you're typing a URL, and then you press "enter", FF3 loads the history entry underneath the cursor, instead of the URL that you typed.

Steps to reproduce:
 0. Clear history, or start with fresh profile. (for easy reproducibility)

 1. Visit these URLs:
     ftp://ftp.mozilla.org/pub
     ftp://ftp.mozilla.org/README

 2. Type "ftp.mozilla.org" into location bar, to trigger AwesomeBar dropdown.  Hover mouse over the second dropdown entry.  ***Do not touch the mouse from here on out.***

 3. Type 'z', so the URL now reads: "ftp.mozilla.org/z"
   ** RESULTS: AwesomeBar dropdown should now be hidden, since we haven't seen this substring before.

 4. Press backspace, to leave location bar with "a.org/p"
   ** RESULTS: AwesomeBar dropdown reappears, with the entry below cursor highlighted.

 5. Press enter.

Expected results: 
  FF loads ftp.mozilla.org

Actual results:
  FF loads the highlighted history entry.  (either ftp.mozilla.org/pub or ftp.mozilla.org/README)

==========

Expected results are based on FF2 behavior.  In FF2, we don't highlight a history entry in the drop-down list unless you **actively move the cursor to be over that entry**.  If the cursor just happens to already be on top of that entry, FF2 doesn't highlight it.  (whereas FF3 does in some occasions, as described above)

Also, for some reason, this only seems to work when the cursor is hovering over a piece of the dropdown that obscures **webpage content area**.  If you hover over the upper part of the first AwesomeBar dropdown item, which is on top of the bookmarks toolbar, then this bug doesn't reproduce.  (i.e. the history entry doesn't become highlighted after step 4, and we correctly load ftp.mozilla.org after step 5)

Comment 2

[Reed Loden [:reed]]

Actually, I don't think this is the same bug as bug 400671. This is a dupe, but not of that bug, I think. Let me see if I can dig up the bug # for the bug I'm thinking about.

Comment 3

[Daniel Holbert [:dholbert]]

(In reply to comment #0)
>  2. Type "ftp.mozilla.org"

Nitpick -- I should say "ftp.mozilla.org/" there. (adding trailing slash)

>  4. Press backspace, to leave location bar with "a.org/p"

Oops -- I didn't update that from an earlier draft of bug summary.  That should say "ftp.mozilla.org/", not "a.org/p"


Also -- I too don't think that this is the same as bug 400671, at least as described in that bug's first comment.  (though maybe that bug's fix will also fix this)

Comment 4

[Daniel Holbert [:dholbert]]

Just tested the posted patch for bug 400671, and it doesn't fix this bug. 
 => Pretty sure this is a different issue. Reopening.

(reed, go ahead and re-dupe this if you find the other bug that you were thinking about in Comment 2)

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to comment #4)
> (reed, go ahead and re-dupe this if you find the other bug that you were
> thinking about in Comment 2)

Just talked to reed in IRC -- he hasn't been able to find that other possible dupe bug, at least not yet.  So, this might not be a dupe of anything, after all.

--> blocking-FF3?

Comment 6

[Mike Connor [:mconnor]]

hmm, WFM on Mac trunk, the pointer is hidden until you move the mouse again once you start typing.  is the behaviour different on Linux?

Comment 7

[Reed Loden [:reed]]

(In reply to comment #6)
> hmm, WFM on Mac trunk, the pointer is hidden until you move the mouse again
> once you start typing.  is the behaviour different on Linux?

Yes, the behavior is different, making this one of the more annoying bugs on Linux. :/

Comment 8

[Daniel Holbert [:dholbert]]

Seth and I just looked at this in a bit more detail -- it looks like this is more specifically caused by the entry under the cursor being selected **at the moment the dropdown list appears**.

This happens in these situations:
 1. Start with a cleared location bar. Type 1 character, or paste in some substring of a URL in your history.
 2. (as described in comment 0) start with a substring that doesn't appear in your history, and then remove part of it so that it does match something in your history.

If the cursor is over the area where the drop-down box appears, then in both of those situations, the entry under the cursor will be selected.  (and it shouldn't be.)

We tried this on Windows, too, and the bug doesn't happen there -- it looks like this is Linux-only.

ALSO: It looks like the Search Box has the same bug!

Comment 9

[(not reading, please use [e-mail] instead)]

I have a theory, but I need some help from someone with a linux build.

can someone put a dump() in mousemove handlers (there are two, one for the tree version and one for the richlist version) in autocomplete.xml?

I'm wondering if on linux, unlike mac or windows, we are some how creating mousemove events?

If we were, we would see that something like

onxblmousemove() (the mousemove handler in autocomplete.xml)
which would call selectItem() in
which would call set_selectedIndex() in listbox.xml (the selectedIndex setter)

I'm looking to see if mousemove is getting called in dholbert's scenario (it is not on windows, until I actually move the mouse.)

Comment 10

[Martijn Wargers (dead)]

Sorry, I don't have a linux debug build at hand (and it would be very painful and difficult for me, atm, to make one).
Just to confirm, I don't see this bug on windows.
Maybe this is somehow related to bug 321794?

Comment 11

[Daniel Holbert [:dholbert]]

(In reply to comment #10)
> Just to confirm, I don't see this bug on windows.

Yup, Linux-only.

> Maybe this is somehow related to bug 321794?

Great, yeah!  That bug's description ("single
mousemove only when the div appears") sounds exactly like the problem Seth was talking about at the end of in comment #9.

Comment 13

[Jeffrey Baker]

Seth, I added dump() statements and one of the mousemove handlers does indeed fire.  It's the first one, attached to autocomplete-richlistbox.  The one attached to autocompelte-treebody does not fire.

Comment 14

[(not reading, please use [e-mail] instead)]

jeffery, thanks for doing that!

you would see the dump in the autocomplete-treebody mousemove handler when you reproduced this bug with the search bar autocomplete (or web content autocomplete) which uses the tree version (instead of the richlistbox).

this definitely sounds related to bug #321794

Comment 15

[Sylvain Pasche]

Regression range:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-07-23+04%3A00&maxdate=2007-07-24+04%3A00&cvsroot=%2Fcvsroot

This range does not confirm that the cause is bug #321794 (it is a followup from bug 321643 which was checked in around 2005-12-29). Moreover, the testcase from 321643 is not showing me the issue.

Comment 16

[Sylvain Pasche]

Some information I could gather:

When the autocomplete panel opens, an event is thrown from GTK calling nsWindow::OnLeaveNotifyEvent. This dispatches a NS_MOUSE_EXIT event.

Then in nsEventStateManager::PreHandleEvent(), the mouse exit event is transformed into a mouse move event (see bug 297080). That move event arrives on the tree of the autocomplete.

I guess bug 388359 regressed this because TranslateWidgetToView was not computed correctly with popups, so the mouse move event was not generated.

I tried to build a testcase where a panel opens above mouse cursor, but I don't get mousemove event dispatched on the panel. I found that in http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/content/events/src/nsEventStateManager.cpp&rev=1.726&mark=838#838 parentWidget is null, so that the move event is not generated. I don't know why.

I'm clearing the dependency on bug 321794 as it doesn't look like to be the cause.

Comment 17

[Sylvain Pasche]

(In reply to comment #16)
> Then in nsEventStateManager::PreHandleEvent(), the mouse exit event is
> transformed into a mouse move event (see bug 297080).

That's rather bug 125386

Comment 19

[Sylvain Pasche]

attachment on bug 297080 (https://bugzilla.mozilla.org/attachment.cgi?id=290695) fixes the issue. I didn't check what it could regress though.

Comment 20

[Matt Hughes]

I experienced this on Linux as well (FF 3 Beta 2 on Ubuntu).  It appears my mouse is moving a pixel or two as if I type while keeping the mouse perfectly still it doesn't select.

I propose one of two things:

-- Ignore the mouse move unless it has moved some minimum distance (like 5 pixels); it's unlikely that someone will accidentally move the mouse that much and just as unlikely the someone purposely moves the mouse that little
-- As the user starts typing in the location bar, move the mouse pointer outside the selection range; preferably just to the right of it.

This bug is really annoying especially if you have big history as the autocomplete fills up a big part of the screen, increasingly the likelihood that your mouse will be in the way.  Maybe a parallel solution would be to limit the size of the autocomplete div?

Comment 21

[Matthew Gregan [:kinetik]]

Using current trunk, I can reproduce this using dholbert's steps.  With my patch for bug #297080 (which is Martijn's nsEventStateManager.cpp patch plus gtk2 widget support for generating mouse exits based on his Win32 code) applied, the problem does not occur.  So, yeah, basically confirming what Sylvain said in comment #19.

Comment 28

[Johnny Stenback (:jst)]

I'm seeing this all the time too, as are others around here that are using Linux it seems. Upping priority on this one as I think it's annoying enough to keep loading the wrong URL half the time you use the URL bar.

Comment 30

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Is the idea of bug 297080 fixing this that it would fix only the case where the mouse doesn't move, but still leave broken the case where the mouse moves a pixel or two?

It seems like, fundamentally, moving the mouse shouldn't do selection.  If the autocomplete widget wants a :hover style for the items, that's great, but we shouldn't confuse it with a selection.

(I think this reminds me of a bug from a number of years ago that was almost the same, but I can't find it.)

Comment 31

[Roman R.]

Position of the mouse cursor should be ignored entirely. Selection should only be made by a click or arrow keys. But if the location bar's value is edited last, its value should be taken as the desired URL.

Comment 32

[Matthew Gregan [:kinetik]]

(In reply to comment #30)
> Is the idea of bug 297080 fixing this that it would fix only the case where the
> mouse doesn't move, but still leave broken the case where the mouse moves a
> pixel or two?

That's right.

> It seems like, fundamentally, moving the mouse shouldn't do selection.  If the
> autocomplete widget wants a :hover style for the items, that's great, but we
> shouldn't confuse it with a selection.

I agree, and I accidentally select items from the autocomplete dropdown with the current behaviour quite regularly.  I have a habit of sweeping the mouse cursor away after selecting the location bar, but sometimes I forget until I've begun typing.

Since 297080 covers the specific selection after no-mouse-movement bug, should we morph this into a general bug abut selection-from-movement, or open a new one?  Opening a new bug seems cleaner to me.

Comment 34

[Dotan Cohen]

I can confirm this bug in Firefox2 as well. It's bothered me for ages.

Comment 35

[u294409]

Dotan, Firefox has been heavily rewritten and improved.
This bug is about third version (even: generation) of Firefox.

Locationbar has been rewritten too, causing some bugs, but not without improving the usability ;) .

Comment 36

[Daniel Holbert [:dholbert]]

(In reply to comment #34)
> I can confirm this bug in Firefox2 as well. It's bothered me for ages.

Doron -- as Jakub said, this is a FF3-only bug AFAIK.  The steps described in Comment 0 (amended in Comment 3) do *not* reproduce the bug in FF2 for me.

If a similar set of steps reproduce a similar bug in FF2, you should probably file a new bug on that, as it'd almost certainly be due to a separate problem.  (This bug here is due to new code introduced since FF2 -- note that the bonsai link in Comment 15 indicates this broke due to code checked in on 2007-07-23)

Comment 37

[Daniel Holbert [:dholbert]]

(In reply to comment #36)
> Doron

Oops -- my mistake -- 'Dotan'. :)  I misread your name.  Sorry about that.

Comment 38

[Dotan Cohen]

Thank you Daniel. Don't worry, I've been called worse!

So long as this problem will be fixed in a future version of Firefox, I see no reason to waste developer resources filing it in the current version. I can live with the problem until Firefox3 is released. Thanks.

Last note: the same problem happens in the context menu in Fx2 as well as in the address bar. So you may want to check for that in Fx3.

Comment 41

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I filed bug 417053 on comment 30.

Comment 42

[Thiago Teixeira]

This bug persists in Firefox 3 beta 3

Comment 47

[Wil Clouser [:clouserw]]

I've had friends installing the oldbar extension because they are so frustrated with this.  For someone that has never used the awesomebar this can be construed as (annoying) default behavior and it really takes the awesome out of our sails.

Comment 48

[X x]

Argh.. this is driving me insane. Nice to see that there is a workaround at least.

Comment 50

[Sylvain Pasche]

Attachment: patch, v1

This patch adds a threshold to the mouse movement before it changes the selection (idea from comment 20). This should kill two birds with one stone:
* Fix this bug (for Linux)
* Avoid the accidental selection change if your mouse moves a few pixels unintentionally as described in comment 30. This is for any platform.

Comment 51

[bugzilla1]

Why not just have it deselect if you keep typing?

Comment 52

[Hans Schmucker]

Another way would be sticky highlights. I'll simply reposts my comments from bug #417930 , I hope nobody minds:

I'd suggest to split the focus for the location bar and the suggestion list... 

---------------------------------------------------------------------------

Location bar focused -> ArrowKeyDown : Suggestion list gets focused. If a
suggestion entry is selected, select next entry. Otherwise select first entry.

Location bar focused -> ArrowKeyUp : Suggestion list gets focused. If a
suggestion entry is selected, select previous entry. Otherwise select last
entry.

Location bar focused -> Enter : Launch currently typed in address.

Location bar focused -> Escape : Unfocus Location bar.

Location bar focused -> OnMouseOver Suggestion List: Select entry but don't
focus (dimmed selection).

Location bar focused -> OnClick Suggestion List: Copy entry location to
location bar, launch.

---------------------------------------------------------------------------

Suggestion list focused -> ArrowKeyDown: If last entry selected, unselect
entry, focus location bar.

Suggestion list focused -> ArrowKeyUp: If first entry selected, unselect entry,
focus location bar.

Suggestion list focused -> Enter : Launch currently selected suggestion.

Suggestion list focused -> Escape : Unfocus selection list (dim, but don't
remove highlight), focus Location bar.

Suggestion list focused -> OnClick Location bar : Unfocus Suggestion list (dim,
but don't remove highlight).

---------------------------------------------------------------------------



That way enter would only mean launch when the Suggestion list is actually
active.

Comment 53

[Neil Deakin]

The right fix here is to not have the autocomplete textbox use the popup's selection when Enter is pressed. When the address field is focused, it should load the url in addressbar.value. What the popup is doing or any state of it should have no affect on what the Enter key does.

Conveniently, the completeselectedindex attribute is used on the autocomplete which means that the addressbar.value is changed when keyboard navigation is done, so pressing Enter here will do the right thing for keyboard only use.

When completeselectedindex is false, we should either leave the behaviour as is, or only have Enter use the popup value when the cursor keys were used to navigate (in which case the popup should probably just take the focus instead).


 
 

Comment 54

[Neil Deakin]

Attachment: patch as described

Not sure how to make browser tests; maybe someone can create one for this.

Comment 55

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

I don't see how that patch is related to this bug. The URL bar uses completeselectedindex="true" so that patch isn't going to affect it, and the problem really is at step 4 of comment 0, which is caused by bug 297080 (and could potentially be worked around if we fix bug 417053).

Comment 56

[Neil Deakin]

(In reply to comment #55)
> I don't see how that patch is related to this bug. The URL bar uses
> completeselectedindex="true" so that patch isn't going to affect it,

Because completeselectedindex is true, the call to GetResultValueAt which fills in the selected value from the popup when enter is pressed will be skipped:

-  if (selectedIndex >= 0)
+  if (selectedIndex >= 0 && !completeSelection)
     GetResultValueAt(selectedIndex, PR_TRUE, value);

> the problem really is at step 4 of comment 0, which is caused by bug 297080 (and

I can't actually reproduce the problem given the steps in comment 0. I do see the problem of the wrong url being used when enter is pressed.

Bug 417053 is a possible fix, although it is arguably invalid, as menus do not behave this way (with the mouse not affecting the selected item) and one could say that the autocomplete popup should behave in the same way.

Comment 57

[Mike Beltzner [:beltzner, not reading bugmail]]

What is clear, and what I *think* Neil's patch does (if I'm reading comment 53 correctly) is say that hitting ENTER uses what's in the text field, not what's selected in the autocomplete dropdown. In the case where I use the keyboard to move between those entries, that also changes what's the the text field, so hitting ENTER will work as expected.

Comment 58

[Daniel Holbert [:dholbert]]

(In reply to comment #56)
> I can't actually reproduce the problem given the steps in comment 0.

FWIW, I still can reproduce it in latest-trunk.


Neal, did you see this last part of Comment 0?  It definitely affects the bug's reproducibility, so it may explain why you're not seeing it:

> this only seems to work when the cursor is hovering over
> a piece of the dropdown that obscures **webpage content area**.  If you hover
> over the upper part of the first AwesomeBar dropdown item, which is on top of
> the bookmarks toolbar, then this bug doesn't reproduce.  (i.e. the history
> entry doesn't become highlighted after step 4, and we correctly load
> ftp.mozilla.org after step 5)
 
(also, if it's not clear, "this only seems to work" means "this only seems to reproduce the bug")

Comment 59

[Daniel Holbert [:dholbert]]

(In reply to comment #58)
> Neal, did you see this last part of Comment 0?  It definitely affects the 

s/Neal/Neil/

Comment 60

[Neil Deakin]

> 
> Neal, did you see this last part of Comment 0?  It definitely affects the bug's
> reproducibility, so it may explain why you're not seeing it:
> 
Gavin suggested above that step 4 was where the problem was (pressing backspace). That doesn't cause a problem for me, and I saw afterwards your corrected step in comment 3. I thought that perhaps I was missing some aspect of what the bug was about, but I don't think that's the case.

Comment 61

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

(In reply to comment #60)
> Gavin suggested above that step 4 was where the problem was (pressing
> backspace).

Just to be clear, the root cause of all these problems is that it's possible for an autocomplete entry to be selected after the text that was typed in to get that entry has changed.

I thought this was only occuring unintentionally due to bug 297080 (which only affects Linux as far as I can tell), but I see similar issues on Windows, without any mouse involvement:

1) type in "ftp.moz"
2) press down to select "ftp://ftp.mozilla.org/pub/"
3) press backspace 3 times to get "ftp://ftp.mozilla.org/p"

This results in the location bar containing "ftp://ftp.mozilla.org/p" while the "ftp://ftp.mozilla.org/pub/" entry is still selected. The backspace should be clearing the selection. Oddly enough I can only reproduce in a nightly build and not my own trunk build. Perhaps something strange related to the profile.

In any case, your patch will fix the symptom by not allowing the selection to replace the URL bar value if completeSelection is true, which is the case for the location bar. The incorrect comment in the patch threw me off.

Comment 62

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

Comment on attachment 306031 [details] [diff] [review]
patch as described

>Index: toolkit/components/autocomplete/src/nsAutoCompleteController.cpp

>+    // If completeselectedindex is false and a row is selected in the popup,
>+    // enter it into the textbox. If completeselectedindex is false, don't
>+    // fill in the value as it will have already been filled in as needed.

Second sentence should start with "if completeselectedindex is _true_".

Comment 63

[u294409]

I think that users of touchpads or numpad mouse emulation like to use enter...

Comment 64

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

Comment on attachment 306031 [details] [diff] [review]
patch as described

Actually, this will break using the mouse to select an autocomplete item. We only update the textbox value for key-triggered selections (in nsAutoCompleteController::HandleKeyNavigation), while the autocomplete popup's click handler just calls nsAutoCompleteController::HandleEnter and depends on this code always getting the selected value.

Comment 65

[Neil Deakin]

> 1) type in "ftp.moz"
> 2) press down to select "ftp://ftp.mozilla.org/pub/"
> 3) press backspace 3 times to get "ftp://ftp.mozilla.org/p"
> 
> This results in the location bar containing "ftp://ftp.mozilla.org/p" while the
> "ftp://ftp.mozilla.org/pub/" entry is still selected.

I can't reproduce that issue. It isn't what this bug is about though.

> Actually, this will break using the mouse to select an autocomplete item.

How odd. I'm sure that was working, but I'll investigate.

Comment 66

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

Well, this bug as originally filed was able accidental selections due to bug 297080. I'm just mentioning the other case because it's another way to get an "accidental selection". If we fixed all the cases where we people select autocomplete items unintentionally we wouldn't need to avoid using the selected item in EnterMatch().

Comment 67

[Neil Deakin]

(In reply to comment #66)
> we wouldn't need to avoid using the selected item in EnterMatch().

I don't think that EnterMatch should be doing anything with the selected item in the popup -- at least not for the urlbar. Pressing Enter should load the value in the textbox and nothing else.

Comment 68

[[e-mail] (:bhearsum)]

(In reply to comment #67)
> (In reply to comment #66)
> > we wouldn't need to avoid using the selected item in EnterMatch().
> 
> I don't think that EnterMatch should be doing anything with the selected item
> in the popup -- at least not for the urlbar. Pressing Enter should load the
> value in the textbox and nothing else.
> 

When browsing through items in the awesomebar with the arrow keys, pressing enter _should_ (imho) load the selected entry. However, if editing is performed on the url it should load the address bar (again, imho).

Comment 69

[Dave Townsend [:mossop]]

(In reply to comment #68)
> When browsing through items in the awesomebar with the arrow keys, pressing
> enter _should_ (imho) load the selected entry. However, if editing is performed
> on the url it should load the address bar (again, imho).

Yes but as you browse around it enters the selected url into the url bar, so that will still work.

Comment 70

[[e-mail] (:bhearsum)]

Sorry, I must've misunderstood the statement!

Comment 71

[Neil Deakin]

Attachment: this patch works for both key and mouse input

Comment 72

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

Comment on attachment 306271 [details] [diff] [review]
this patch works for both key and mouse input

Need to fix the two handleEnter callers in autocomplete.xml too (guess you probably just forgot to include that file in the diff?). r=me with that.

Comment 73

[Neil Deakin]

Attachment: forgot to include autocomplete.xml

Comment 74

[Mukunda]

(In reply to comment #65)
> > 1) type in "ftp.moz"
> > 2) press down to select "ftp://ftp.mozilla.org/pub/"
> > 3) press backspace 3 times to get "ftp://ftp.mozilla.org/p"
> > 
> > This results in the location bar containing "ftp://ftp.mozilla.org/p" while the
> > "ftp://ftp.mozilla.org/pub/" entry is still selected.
> 
> I can't reproduce that issue. It isn't what this bug is about though.

I'm able to reproduce that behavior on Linux with Firefox 3.0 beta 3

Comment 75

[Frédéric Buclin]

Is the patch ready for b4?

Comment 76

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 306357 [details] [diff] [review]
forgot to include autocomplete.xml

a1.9b4=beltzner, this is good for beta testing ...

Comment 77

[kosver]

It is now fixed for my, except if you only type one letter. Then the entry is selected that is under my mouse if I'm using my keyboard. When you type the second character, the selection goes away.

Comment 78

[Daniel Holbert [:dholbert]]

I don't see the issue Nikos mentions - if I type "g" and press enter, we attempt to load the url "g", not the entry under the mouse cursor.

This bug, as described in comment 0, looks fixed to me using this morning's nightly:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4pre) Gecko/2008030304 Minefield/3.0b4pre

==> Marking verified.

Thanks everyone for the hard work on this -- this makes the Firefox 3 experience on Linux SO much nicer. :)

One remaining issue is that the entry under the mouse cursor still gets *highlighted* when the autocomplete pane appears, even though it's not "selected" in the sense of being loaded when the user presses enter.  This highlighting is a change ( / regression) from FF2, so I'll file a new bug on this.

Comment 79

[Daniel Holbert [:dholbert]]

(In reply to comment #78)
> I don't see the issue Nikos mentions - if I type "g" and press enter, we
> attempt to load the url "g", not the entry under the mouse cursor.

Oops, I think I just misunderstood Nikos.  I think he's describing the same remaining issue I mentioned here:

> One remaining issue is that the entry under the mouse cursor still gets
> *highlighted* when the autocomplete pane appears

... which I just filed as bug 420804.

Comment 80

[Roman R.]

I think that the new title of this issue ("don't use selected autocomplete entry when pressing Enter in input (url bar)") is incorrect because implementing it will lead to disabling selection of autocomplete entries by pressing Enter, which is what keyboard users do. For this title to be correct, it has to include editing the URL bar's value.

Comment 81

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

Sure, the summary wasn't quite clear. The point is that we'll always use the input field's value, rather than the value of the selected item. If completeselectedindex is true (which is the case for the URL bar), that value will be the same as the currently selected item, assuming you've selected it with the keyboard rather than the mouse.

Comment 84

[[e-mail]]

I checked in a bustage fix for xpfe autocomplete which also calls handleEnter.

Comment 85

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

I've updated http://developer.mozilla.org/en/docs/nsIAutoCompleteController#handleEnter.28.29 , but this change should probably be highlighted in one of the "Firefox 3 changes" documents.

Comment 86

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

Although I guess it's not that relevant to _users_ of autocomplete, only to people implementing nsIAutocompleteInput/nsIAutocompletePopup.

Comment 87

[Eric Shepherd [:sheppy]]

This is now mentioned here: http://developer.mozilla.org/en/docs/Updating_extensions_for_Firefox_3#Autocomplete

Comment 88

[Thiago Teixeira]

This is fixed in Beta 4.

Comment 89

[kosver]

I can confirm that it's fixed in Beta4, but it has a subtle bug.

The bar highlight the entry below the mouse (either ftp.mozilla.org/pub or
ftp.mozilla.org/README), but goes to the right url (ftp.mozilla.org). I think it should always load the entry it is highlighting. (So it is highlighting the wrong entry) 

Steps to reproduce:
 0. Clear history, or start with fresh profile. (for easy reproducibility)

 1. Visit these URLs:
     ftp://ftp.mozilla.org/pub
     ftp://ftp.mozilla.org/README

 2. Type "ftp.mozilla.org" into location bar, to trigger AwesomeBar dropdown. 
Hover mouse over the second dropdown entry.  ***Do not touch the mouse from
here on out.***

 3. Type 'z', so the URL now reads: "ftp.mozilla.org/z"
   ** RESULTS: AwesomeBar dropdown should now be hidden, since we haven't seen
this substring before.

 4. Press backspace, to leave location bar with "ftp.mozilla.org"
   ** RESULTS: AwesomeBar dropdown reappears.

Expected results: 
  The AwesomeBar doens't select anything, because your busy with your keyboard.

Actual results:
  The AwesomeBar highlight history entry.  (either ftp.mozilla.org/pub or
ftp.mozilla.org/README)

Comment 90

[Martijn Wargers (dead)]

Nikos, please file a new bug for that issue (and mention the bug number here).

Comment 91

[kosver]

(In reply to comment #89)
> I can confirm that it's fixed in Beta4, but it has a subtle bug.
> 
> The bar highlight the entry below the mouse (either ftp.mozilla.org/pub or
> ftp.mozilla.org/README), but goes to the right url (ftp.mozilla.org). I think
> it should always load the entry it is highlighting. (So it is highlighting the
> wrong entry) 
> 
> Steps to reproduce:
>  0. Clear history, or start with fresh profile. (for easy reproducibility)
> 
>  1. Visit these URLs:
>      ftp://ftp.mozilla.org/pub
>      ftp://ftp.mozilla.org/README
> 
>  2. Type "ftp.mozilla.org" into location bar, to trigger AwesomeBar dropdown. 
> Hover mouse over the second dropdown entry.  ***Do not touch the mouse from
> here on out.***
> 
>  3. Type 'z', so the URL now reads: "ftp.mozilla.org/z"
>    ** RESULTS: AwesomeBar dropdown should now be hidden, since we haven't seen
> this substring before.
> 
>  4. Press backspace, to leave location bar with "ftp.mozilla.org"
>    ** RESULTS: AwesomeBar dropdown reappears.
> 
> Expected results: 
>   The AwesomeBar doens't select anything, because your busy with your keyboard.
> 
> Actual results:
>   The AwesomeBar highlight history entry.  (either ftp.mozilla.org/pub or
> ftp.mozilla.org/README)
> 

see bug 422086

Comment 93

[Ron Baldwin]

I thought this bug was for all autocomplete textboxes, but it appears that only the URL bar was fixed.  I filed bug 422948 for the same issue for autocomplete textboxes in a web page.