Closed Bug 79069 Opened 20 years ago Closed 12 years ago

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

Categories

(SeaMonkey :: Location Bar, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
seamonkey2.0b1

People

(Reporter: doctor__j, Assigned: neil)

References

Details

Attachments

(1 file)

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.
:(
Assignee: alecf → hewitt
Status: UNCONFIRMED → NEW
Ever confirmed: true
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → Future
Summary: Enter key override mouse clicks in Autocomplete → Enter key should only go to selected autocomplete item if keyboard was used to select item
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.
*** Bug 100337 has been marked as a duplicate of this bug. ***
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?
Severity: enhancement → normal
OS: Windows 98 → All
Hardware: PC → All
Catfood.
Keywords: nsCatFood
*** Bug 155699 has been marked as a duplicate of this bug. ***
I do this [accidentally do the search by pressing enter with mouse on search]
all the time, can confirm it is annoying! Thanks.
I've also been hitting this.
Bug 230677 is the same bug for Firefox.
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).
Assignee: hewitt → location-bar
Status: ASSIGNED → NEW
Priority: P3 → --
QA Contact: claudius
Target Milestone: Future → ---
Duplicate of this bug: 375953
See also bug 376868, a similar bug for form autocomplete in Firefox.
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.
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.
(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.)
(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.
(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.
It's also a regression compared to five weeks ago, so it's my fault :-(
Assignee: location-bar → neil
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.
Attachment #274692 - Flags: superreview?(jag)
Attachment #274692 - Flags: review?(kairo)
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.
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 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.
Attachment #274692 - Flags: review?(kairo) → review+
Attachment #274692 - Flags: superreview?(jag) → superreview+
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.
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.
Flags: blocking1.9?
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.
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.
(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?
No, menus are OK.
-'ing.  Sounds like this is checked in.  Please re-nom if an issue or close this bug if actually checked in.
Flags: blocking1.9? → blocking1.9-
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.
Sander, do you also see what I described in comment 26?
Product: Core → SeaMonkey
(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.
Flags: blocking-seamonkey2.0b1?
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.  :/
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.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Flags: blocking-seamonkey2.0b1?
Target Milestone: --- → seamonkey2.0b1
Pushed by frgrahl@gmx.net:
https://hg.mozilla.org/comm-central/rev/2a36bd0acce5
Typing should deselect autocomplete search engine b=79069 r=KaiRo sr=jag
You need to log in before you can comment on or make changes to this bug.