pressing Enter in URL bar selects mouse hover target in substring-search pop-down

*** This bug has been marked as a duplicate of bug 400671 ***

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.

(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)

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)

(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?

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?

(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. :/

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!

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.)

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?

(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.

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

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.

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

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.

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.

(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

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

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

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?

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.

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

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

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

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

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

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

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.

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

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.)

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.

(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.

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

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

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 ;) .

(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)

(In reply to comment #36)
> Doron

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

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.

> 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.

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().

(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.

(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).

(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.

Sorry, I must've misunderstood the statement!

Created attachment 306271
this patch works for both key and mouse input

Comment on attachment 306271
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.

Created attachment 306357
forgot to include autocomplete.xml

(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

Is the patch ready for b4?

Comment on attachment 306357
forgot to include autocomplete.xml

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

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.

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.

(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.

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.

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.

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

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

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

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.

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

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

This is fixed in Beta 4.

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)

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

(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

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

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.

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

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

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