79069 - Enter key should only go to selected autocomplete item if keyboard was used to select item

Status: RESOLVED FIXED

(SeaMonkey :: Location Bar, defect)

Description

[doctor__j]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9+) Gecko/20010505
BuildID:    2001050508

Reproducible: Always
Steps to Reproduce:
1. Suppose you got lots of history on bugzilla.mozilla.org
2. Type "bugzi" on the URL bar.
3. You'll see some visited URLs for your choice.  Besides that, the lowest row
has "Search <a search engine> for "bugzi"".

Actual Results:
 (a) If you move the mouse over the visited URLs and press "Enter", you will
*NOT* go to the selected URL.  Instead, you will go to the URL as you typed,
that is, simply "bugzi".  (You need to *click* on the URL to load the suggested
URL.)

 (b) If you move the mouse and select "Search <a search engine> for "bug"" and
press "Enter", you *WILL* go to the search engine and search for "bug", *which*
is not what I expected...


Expected Results:
 (a) Performs as expected.
 (b) Enter key should have no effect upon that situation and only a mouse click
should be able to activate the search.

This is a request for changing autocomplete behavior/response a little bit.  I
think many people will not take that as a bug.  I only wish to bring this up for
discussion.  Coz often I will (unintentionally) locate my mouse cursor on the
"Search <a search engine> for "bugzi"" item and activates the search upon
pressing enter.

Comment 1

[timeless]

:(

Comment 2

[Alfonso Martinez]

I think that many people will have to fight with this bug, as it is quite easy
to activate the wrong behaviour. 
I usually click with the mouse on the url and maybe select a part of it to edit,
then move the mouse a little to the bottom to get out of view, and then it get's
placed where later will appear the "Search...", so I go on with the keyboard and
just press Enter and a google search appears.
If you ever hear that someone claims that Mozilla is trying to search almost all
the things that he types in the URL bar, think about this bug.
I don't think that this is an enhancement, I would say Minor Severity instead.

Comment 3

[Alfonso Martinez]

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

Comment 4

[Claudius Gayle]

I view this as a bona fide bug, more than just a mere enhancement or minor
annoyance. This behavior is just plain wrong. It is made even more
difficult/confusing by the fact that the autocomplete items behave correctly and
only the search item misbehaves.

hewitt, is it possible to reel in the target milestone some?

Comment 5

[Jonas Jørgensen]

Catfood.

Comment 6

[Alfonso Martinez]

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

Comment 7

[Aaron Lawrence]

I do this [accidentally do the search by pressing enter with mouse on search]
all the time, can confirm it is annoying! Thanks.

Comment 8

[Jesse Ruderman]

I've also been hitting this.

Comment 9

[Jesse Ruderman]

Bug 230677 is the same bug for Firefox.

Comment 10

[Andrew Schultz]

This is a nasty bug.  The issue is that the search engine is "selected" and the user hits enter, so it invokes the search engine.  Ideally, hitting enter would only search if the search engine had been selected via keyboard.

The autocomplete widget is the only thing that might know whether the user navigated to an element via keyboard or not and the browser (urlbarBindings) has to decide whether the search engine got selected or not.  Oh, and the autocomplete widget doesn't know anyway (although remembering wouldn't be hard, it would take another flag or somehow piggy-back on mTransientValue).

Comment 12

[Jesse Ruderman]

See also bug 376868, a similar bug for form autocomplete in Firefox.

Comment 13

[Robert Kaiser]

Chris/Neil, is there anything easy we can do about this, at least on trunk?

I often click into the urlbar, typing something there after moving the mouse away just a tad to not have the mouse pointer distract the view, and press enter afterwards - and end up searching that URL on Google, which is my default search engine!

This bug seems to mean that when the "Search Google for '...'" bar is being displayed because of my typing, and the mouse pointer happens to be over it (even it it already was before I started typing), pressing the enter key actually triggers that search bar instead of the normal URLbar. This sounds clearly wrong to me.
Pressing enter after typing in the urlbar (with the text caret visible in the urlbar!) should never go to the search engine for searching on a perfectly valid URL.

Comment 14

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Dunno.  I hate this bug too (but apparently not enough to look into it myself).  A hack would be to monitor whether we most recently got a kbd event of mouse event.

Comment 15

[[e-mail]]

(In reply to comment #14)
>A hack would be to monitor whether we most recently got a kbd event of mouse event.
We already appear to clear the search engine selection when you type. (Tested using a five-week-old build so I might have regressed it since by mistake.)

Comment 16

[Robert Kaiser]

(In reply to comment #15)
> We already appear to clear the search engine selection when you type. (Tested
> using a five-week-old build so I might have regressed it since by mistake.)

At least when the mouse is still over the search bar, the bar has some focus (shown by is using the hover background color) and is called when pressing enter - even when typing and not touching the mouse before pressing enter.

Comment 17

[Bruno 'Aqualon' Escherl]

(In reply to comment #16)
> even when typing and not touching the mouse before pressing enter.
That's a regression compared to branch behavior. In SM 1.1.3 the search engine selection looses focus when typing, in trunk the focus stays on the search bar.

Comment 18

[[e-mail]]

It's also a regression compared to five weeks ago, so it's my fault :-(

Comment 19

[[e-mail]]

Attachment: Typing should deselect search engine

This patch fixes the regression from the satchel changes. As it's not easy to override the selectedIndex setter I have instead added a new API and also reworked some of the existing code to use the new API.

Comment 20

[Robert Kaiser]

From what I saw on a first test, this seems to fix the real-world problem of typing after moving the mouse. If you move the mouse over the bar after typing and press enter, still the search is performed, but that might even be reasonable and expected, even if comment #0 almost sounds like complaining about that.

Comment 21

[Jesse Ruderman]

No, moving the cursor should not affect what Enter does.  That's totally inconsistent with how WIMP usually works, and it's problematic for mouse users, where a tiny nudge or bumping the table causes the cursor to move by a few pixels.

Comment 22

[Robert Kaiser]

Comment on attachment 274692 [details] [diff] [review]
Typing should deselect search engine

I don't really know the code well enough for reviewing, but I have run with it a few days and it seems to work well. I hope jag will do the real code review in his sr.

Comment 23

[[e-mail]]

Fix checked in, so we are now back to the point where typing clears the search engine so that it's not incorrectly selected when you hit enter. No progress on making Enter ignore a mouseover of the search engine though.

Comment 24

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

Requesting blocking-1.9 since the following use case bites pretty hard, and isn't platform-parity compliant on any OS:

 - user focuses a textbox
 - user moves the mouse down and out of the way, item is selected
 - user hits enter, selected item is loaded

Fixing this would mean that hitting enter would only load that item if it was selected by keyboard-then-enter or by mouse-click.

Comment 25

[[e-mail]]

By my testing we have parity with IE6 for both URLbar and in-page autocomplete i.e. Enter ignores mouse hover only for URLbar autocomplete.

Comment 26

[Andrew Schultz]

Note that we don't actually have parity with SM 1.1.x behavior.  In 1.1, if you type a letter and that causes the autocomplete dropdown to appear and you hit enter, you won't go to the autocomplete entry.  An entry is never selected unless you actually move the mouse.  On trunk, if the dropdown opens and the mouse is over an entry, that entry is selected (and further typing deselects it).  I get bitten by this fairly often.

Comment 27

[[e-mail]]

(In reply to comment #26)
>On trunk, if the dropdown opens and the mouse is over an entry, that entry is selected
Might be a Linux regression; I don't see that on Windows. If you open a menu with the keyboard, does it get confused if it opens under the mouse?

Comment 28

[Andrew Schultz]

No, menus are OK.

Comment 29

[Damon Sicore (:damons)]

-'ing.  Sounds like this is checked in.  Please re-nom if an issue or close this bug if actually checked in.

Comment 30

[Sander]

I found a case where enter still causes a search to be triggered when it shouldn't (on windows, at least):
1) visit http://meyerweb.com/eric/thoughts/2008/01/23/version-two/ 
2) visit http://meyerweb.com/eric/thoughts/2008/01/23/version-two/#comments
3) move the mouse to hover over the tab-bar (not the personal toolbar, not the page itself)
4) using the keyboard, navigate to the end of the URL and shift-left to select the #comments part of the URL
5) hit delete (this should show an autocomplete drop-down with three items: the two visited URLs, and the search)
6) hit enter

expected result: visit http://meyerweb.com/eric/thoughts/2008/01/23/version-two/
actual result: visit the search page for "http://meyerweb.com/eric/thoughts/2008/01/23/version-two/"

The key parts here are hovering the mouse over the tab-bar, and having the search result (not another autocomplete item) show up underneath the mouse. You can cause the same to happen by backspacing, although the search result only gets selected upon the first backspace which causes it to appear underneath the mouse, with it being deselected again upon further backspaces.

The steps might appear somewhat obscure, but jumping up to a higher directory in a site by editing the URL is a common enough thing for me to do that I hit this bug several times a week; I just never quite grasped before what was necessary to trigger it.

Comment 31

[Andrew Schultz]

Sander, do you also see what I described in comment 26?

Comment 33

[Rich Gray (:rbgray)]

(In reply to comment #26)
> Note that we don't actually have parity with SM 1.1.x behavior.  In 1.1, if you
> type a letter and that causes the autocomplete dropdown to appear and you hit
> enter, you won't go to the autocomplete entry.  An entry is never selected
> unless you actually move the mouse.  On trunk, if the dropdown opens and the
> mouse is over an entry, that entry is selected (and further typing deselects
> it).  I get bitten by this fairly often.

I can keep trackpad pointer the in the URL field and still do a search when Enter is hit:

1. goto https://www.verisign.com
2. click on the location bar - it selects the whole url
3. click again to get a cursor.
4. move the cursor to the 's' in https: using arrow keys or mouse (trackpad in my case)
5. hit Delete to delete the 's' - the search dropdown appears and is selected.
6. hit Enter, intending to go to the non-secure Verisign - wind up doing a search for the url instead.

One must hit up arrow to move the selection/focus back to the URL field before hitting Enter. (Which is contradictory to the visual appearance.  When I hit up arrow, the search drop down changes from white to blue.    Isn't blue supposed to be the selection?  When there's more than one item, that seems to be the case.)  Ah, I see the "mouse" part of this too.  Nudging the mouse up a little (even though it still should have been pointing at the URL field) seems to avoid the search.  Note that I was testing in a virgin account, created for the smoke test, so there was no history.  Perhaps that's why it's so pronounced.  Once one has been to a site, autocomplete masks the problem.


This is my first time smoke testing SM2 so this jumped out at me right away.  I've never noticed it in 1.x.  For a user transitioning from 1.x, this is a really ugly regression IMHO.  Nominating to block SM2 beta1.

Comment 34

[Rich Gray (:rbgray)]

Uh, forgot to include the build id: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090223 SeaMonkey/2.0a3

Sorry for the bug spam.  :/

Comment 35

[Robert Kaiser]

I don't see this in current trunk any more, I guess the recent urlbar fixes from mcsmurf have actually fixed the rest of this. Marking fixed for stuff that has been actually patched in here.

Comment 36

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/2a36bd0acce5
Typing should deselect autocomplete search engine b=79069 r=KaiRo sr=jag