pressing Enter in URL bar selects mouse hover target in substring-search pop-down
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mozilla Firefox |
Fix Released
|
Medium
|
|||
firefox-3.0 (Ubuntu) |
Fix Released
|
Medium
|
Unassigned |
Bug Description
Binary package hint: firefox-3.0
The new substring-search pop-down box attached to the URL bar in Firefox-3.0 is generally very nice, but I have one annoyance with it regarding keyboard navigation. I tend not to use the mouse a great deal, and am in the habit of pressing Ctrl-t Ctrl-l <type URL> to open a new tab, unless I'm copying and pasting the URL.
Here's a reduced test case. Open a new tab in Firefox-3.0 (current version in Hardy: 3.0~b3~
As described, I suppose this is not so annoying, but the way I encounter this in practice is that I try to enter "http://
IMHO, pressing Enter should only select an entry from substring-search if you navigated to that entry using the cursor keys. Otherwise, it should require a mouse click to select it. The current way that mouse positioning and keyboard navigation interact is confusing.
Related branches
In Mozilla Bugzilla #408723, Reed Loden (reed) wrote : | #2 |
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 Mozilla Bugzilla #408723, Daniel Holbert (dholbert) wrote : | #3 |
(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)
In Mozilla Bugzilla #408723, Daniel Holbert (dholbert) wrote : | #4 |
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 Mozilla Bugzilla #408723, Daniel Holbert (dholbert) wrote : | #5 |
(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?
In Mozilla Bugzilla #408723, Mike Connor (mconnor) wrote : | #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?
In Mozilla Bugzilla #408723, Reed Loden (reed) wrote : | #7 |
(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. :/
In Mozilla Bugzilla #408723, Daniel Holbert (dholbert) wrote : | #8 |
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!
In Mozilla Bugzilla #408723, Moco (moco) wrote : | #9 |
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.)
In Mozilla Bugzilla #408723, Martijn-martijn (martijn-martijn) wrote : | #10 |
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 Mozilla Bugzilla #408723, Daniel Holbert (dholbert) wrote : | #11 |
(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.
In Mozilla Bugzilla #408723, Moco (moco) wrote : | #12 |
*** Bug 409057 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #408723, Jeffrey Baker (jwbaker) wrote : | #13 |
Seth, I added dump() statements and one of the mousemove handlers does indeed fire. It's the first one, attached to autocomplete-
In Mozilla Bugzilla #408723, Moco (moco) wrote : | #14 |
jeffery, thanks for doing that!
you would see the dump in the autocomplete-
this definitely sounds related to bug #321794
In Mozilla Bugzilla #408723, Sylvain Pasche (sylvain-pasche) wrote : | #15 |
Regression range:
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.
In Mozilla Bugzilla #408723, Sylvain Pasche (sylvain-pasche) wrote : | #16 |
Some information I could gather:
When the autocomplete panel opens, an event is thrown from GTK calling nsWindow:
Then in nsEventStateMan
I guess bug 388359 regressed this because TranslateWidget
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://
I'm clearing the dependency on bug 321794 as it doesn't look like to be the cause.
In Mozilla Bugzilla #408723, Sylvain Pasche (sylvain-pasche) wrote : | #17 |
(In reply to comment #16)
> Then in nsEventStateMan
> transformed into a mouse move event (see bug 297080).
That's rather bug 125386
In Mozilla Bugzilla #408723, Gavin Sharp (gavin-sharp) wrote : | #18 |
*** Bug 409866 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #408723, Sylvain Pasche (sylvain-pasche) wrote : | #19 |
attachment on bug 297080 (https:/
In Mozilla Bugzilla #408723, Hughes-matt (hughes-matt) wrote : | #20 |
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?
Colin Watson (cjwatson) wrote : | #21 |
Binary package hint: firefox-3.0
The new substring-search pop-down box attached to the URL bar in Firefox-3.0 is generally very nice, but I have one annoyance with it regarding keyboard navigation. I tend not to use the mouse a great deal, and am in the habit of pressing Ctrl-t Ctrl-l <type URL> to open a new tab, unless I'm copying and pasting the URL.
Here's a reduced test case. Open a new tab in Firefox-3.0 (current version in Hardy: 3.0~b3~
As described, I suppose this is not so annoying, but the way I encounter this in practice is that I try to enter "http://
IMHO, pressing Enter should only select an entry from substring-search if you navigated to that entry using the cursor keys. Otherwise, it should require a mouse click to select it. The current way that mouse positioning and keyboard navigation interact is confusing.
Alexander Sack (asac) wrote : | #22 |
confirmed. a usability glitch that can be annoying and should be fixed for final.
Changed in firefox-3.0: | |
importance: | Undecided → Medium |
status: | New → Confirmed |
In Mozilla Bugzilla #408723, Matthew Gregan (kinetik) wrote : | #23 |
Using current trunk, I can reproduce this using dholbert's steps. With my patch for bug #297080 (which is Martijn's nsEventStateMan
Changed in firefox: | |
status: | Unknown → Confirmed |
In Mozilla Bugzilla #408723, Reed Loden (reed) wrote : | #24 |
*** Bug 413946 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #408723, Gavin Sharp (gavin-sharp) wrote : | #25 |
*** Bug 414140 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #408723, Stephen-donner (stephen-donner) wrote : | #26 |
*** Bug 414488 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #408723, Supernova00 (supernova00) wrote : | #27 |
*** Bug 414483 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #408723, Philringnalda (philringnalda) wrote : | #28 |
*** Bug 414506 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #408723, Gavin Sharp (gavin-sharp) wrote : | #29 |
*** Bug 414615 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #408723, Jst (jst) wrote : | #30 |
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.
In Mozilla Bugzilla #408723, Elmar-ludwig (elmar-ludwig) wrote : | #31 |
*** Bug 415344 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #408723, L. David Baron (dbaron) wrote : | #32 |
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.)
In Mozilla Bugzilla #408723, R-rom (r-rom) wrote : | #33 |
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 Mozilla Bugzilla #408723, Matthew Gregan (kinetik) wrote : | #34 |
(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-
In Mozilla Bugzilla #408723, Jruderman (jruderman) wrote : | #35 |
*** Bug 416159 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #408723, Mozilla-bugs-2010-04 (mozilla-bugs-2010-04) wrote : | #36 |
I can confirm this bug in Firefox2 as well. It's bothered me for ages.
In Mozilla Bugzilla #408723, Jakub 'Livio' Rusinek (liviopl-pl) wrote : | #37 |
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 Mozilla Bugzilla #408723, Daniel Holbert (dholbert) wrote : | #38 |
(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 Mozilla Bugzilla #408723, Daniel Holbert (dholbert) wrote : | #39 |
(In reply to comment #36)
> Doron
Oops -- my mistake -- 'Dotan'. :) I misread your name. Sorry about that.
In Mozilla Bugzilla #408723, Mozilla-bugs-2010-04 (mozilla-bugs-2010-04) wrote : | #40 |
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.
In Mozilla Bugzilla #408723, Elmar-ludwig (elmar-ludwig) wrote : | #41 |
*** Bug 416575 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #408723, Jruderman (jruderman) wrote : | #42 |
*** Bug 416598 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #408723, L. David Baron (dbaron) wrote : | #43 |
I filed bug 417053 on comment 30.
In Mozilla Bugzilla #408723, Thiago Teixeira (tvst) wrote : | #44 |
This bug persists in Firefox 3 beta 3
In Mozilla Bugzilla #408723, Stephen-donner (stephen-donner) wrote : | #45 |
*** Bug 417900 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #408723, Stephen-donner (stephen-donner) wrote : | #46 |
*** Bug 417930 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #408723, Mikel Ward (mikelward) wrote : | #47 |
*** Bug 418174 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #408723, Stephen-donner (stephen-donner) wrote : | #48 |
*** Bug 418534 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #408723, Wil Clouser (clouserw) wrote : | #49 |
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.
In Mozilla Bugzilla #408723, Thomas Novin (thomasn80) wrote : | #50 |
Argh.. this is driving me insane. Nice to see that there is a workaround at least.
In Mozilla Bugzilla #408723, Sylvain Pasche (sylvain-pasche) wrote : | #51 |
*** Bug 419172 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #408723, Sylvain Pasche (sylvain-pasche) wrote : | #52 |
Created attachment 305372
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.
In Mozilla Bugzilla #408723, Bugzilla1-matt13 (bugzilla1-matt13) wrote : | #53 |
Why not just have it deselect if you keep typing?
In Mozilla Bugzilla #408723, Hansschmucker (hansschmucker) wrote : | #54 |
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.
In Mozilla Bugzilla #408723, Enn (enndeakin) wrote : | #55 |
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 completeselecte
When completeselecte
In Mozilla Bugzilla #408723, Enn (enndeakin) wrote : | #56 |
Created attachment 306031
patch as described
Not sure how to make browser tests; maybe someone can create one for this.
In Mozilla Bugzilla #408723, Gavin Sharp (gavin-sharp) wrote : | #57 |
I don't see how that patch is related to this bug. The URL bar uses completeselecte
In Mozilla Bugzilla #408723, Enn (enndeakin) wrote : | #58 |
(In reply to comment #55)
> I don't see how that patch is related to this bug. The URL bar uses
> completeselecte
Because completeselecte
- if (selectedIndex >= 0)
+ if (selectedIndex >= 0 && !completeSelection)
GetResultV
> 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.
In Mozilla Bugzilla #408723, Beltzner (beltzner) wrote : | #59 |
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.
In Mozilla Bugzilla #408723, Daniel Holbert (dholbert) wrote : | #60 |
(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")
In Mozilla Bugzilla #408723, Daniel Holbert (dholbert) wrote : | #61 |
(In reply to comment #58)
> Neal, did you see this last part of Comment 0? It definitely affects the
s/Neal/Neil/
In Mozilla Bugzilla #408723, Enn (enndeakin) wrote : | #62 |
>
> 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.
In Mozilla Bugzilla #408723, Gavin Sharp (gavin-sharp) wrote : | #63 |
(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.
3) press backspace 3 times to get "ftp://ftp.
This results in the location bar containing "ftp://ftp.
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.
In Mozilla Bugzilla #408723, Gavin Sharp (gavin-sharp) wrote : | #64 |
Comment on attachment 306031
patch as described
>Index: toolkit/
>+ // If completeselecte
>+ // enter it into the textbox. If completeselecte
>+ // fill in the value as it will have already been filled in as needed.
Second sentence should start with "if completeselecte
In Mozilla Bugzilla #408723, Jakub 'Livio' Rusinek (liviopl-pl) wrote : | #65 |
I think that users of touchpads or numpad mouse emulation like to use enter...
In Mozilla Bugzilla #408723, Gavin Sharp (gavin-sharp) wrote : | #66 |
Comment on attachment 306031
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 nsAutoCompleteC
In Mozilla Bugzilla #408723, Enn (enndeakin) wrote : | #67 |
> 1) type in "ftp.moz"
> 2) press down to select "ftp://ftp.
> 3) press backspace 3 times to get "ftp://ftp.
>
> This results in the location bar containing "ftp://ftp.
> "ftp://ftp.
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.
In Mozilla Bugzilla #408723, Gavin Sharp (gavin-sharp) wrote : | #68 |
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 Mozilla Bugzilla #408723, Enn (enndeakin) wrote : | #69 |
(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 Mozilla Bugzilla #408723, Bhearsum-mozilla (bhearsum-mozilla) wrote : | #70 |
(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 Mozilla Bugzilla #408723, Dtownsend (dtownsend) wrote : | #71 |
(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.
In Mozilla Bugzilla #408723, Bhearsum-mozilla (bhearsum-mozilla) wrote : | #72 |
Sorry, I must've misunderstood the statement!
In Mozilla Bugzilla #408723, Enn (enndeakin) wrote : | #73 |
Created attachment 306271
this patch works for both key and mouse input
In Mozilla Bugzilla #408723, Gavin Sharp (gavin-sharp) wrote : | #74 |
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.
In Mozilla Bugzilla #408723, Enn (enndeakin) wrote : | #75 |
Created attachment 306357
forgot to include autocomplete.xml
In Mozilla Bugzilla #408723, Twentyafterfour+bz (twentyafterfour+bz) wrote : | #76 |
(In reply to comment #65)
> > 1) type in "ftp.moz"
> > 2) press down to select "ftp://ftp.
> > 3) press backspace 3 times to get "ftp://ftp.
> >
> > This results in the location bar containing "ftp://ftp.
> > "ftp://ftp.
>
> 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
In Mozilla Bugzilla #408723, Frédéric Buclin (lpsolit-deactivatedaccount) wrote : | #77 |
Is the patch ready for b4?
In Mozilla Bugzilla #408723, Beltzner (beltzner) wrote : | #78 |
Comment on attachment 306357
forgot to include autocomplete.xml
a1.9b4=beltzner, this is good for beta testing ...
In Mozilla Bugzilla #408723, black (blackborn) wrote : | #79 |
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.
Changed in firefox: | |
status: | Confirmed → Fix Released |
In Mozilla Bugzilla #408723, Daniel Holbert (dholbert) wrote : | #80 |
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 Mozilla Bugzilla #408723, Daniel Holbert (dholbert) wrote : | #81 |
(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.
In Mozilla Bugzilla #408723, R-rom (r-rom) wrote : | #82 |
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.
In Mozilla Bugzilla #408723, Gavin Sharp (gavin-sharp) wrote : | #83 |
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 completeselecte
In Mozilla Bugzilla #408723, Ria-klaassen (ria-klaassen) wrote : | #84 |
*** Bug 420923 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #408723, Myk (myk) wrote : | #85 |
*** Bug 421074 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #408723, Neil-httl (neil-httl) wrote : | #86 |
I checked in a bustage fix for xpfe autocomplete which also calls handleEnter.
In Mozilla Bugzilla #408723, Gavin Sharp (gavin-sharp) wrote : | #87 |
I've updated http://
In Mozilla Bugzilla #408723, Gavin Sharp (gavin-sharp) wrote : | #88 |
Although I guess it's not that relevant to _users_ of autocomplete, only to people implementing nsIAutocomplete
In Mozilla Bugzilla #408723, Eshepherd (eshepherd) wrote : | #89 |
This is now mentioned here: http://
Alexander Sack (asac) wrote : | #90 |
this will land in beta 4.
Changed in firefox-3.0: | |
status: | Confirmed → Fix Committed |
In Mozilla Bugzilla #408723, Thiago Teixeira (tvst) wrote : | #91 |
This is fixed in Beta 4.
In Mozilla Bugzilla #408723, black (blackborn) wrote : | #92 |
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.
Steps to reproduce:
0. Clear history, or start with fresh profile. (for easy reproducibility)
1. Visit these URLs:
ftp://ftp.
ftp://ftp.
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.
In Mozilla Bugzilla #408723, Martijn-martijn (martijn-martijn) wrote : | #93 |
Nikos, please file a new bug for that issue (and mention the bug number here).
In Mozilla Bugzilla #408723, black (blackborn) wrote : | #94 |
(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.
> 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.
> ftp://ftp.
>
> 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.
>
see bug 422086
Daniel Persson (daniel-danielpersson) wrote : | #95 |
Great news, I was searching for a workaround since I also find this behavior not very intuitive. Now I just have to wait for next Beta.
In Mozilla Bugzilla #408723, Gavin Sharp (gavin-sharp) wrote : | #96 |
*** Bug 421074 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #408723, Bogofilter+mozilla-org (bogofilter+mozilla-org) wrote : | #97 |
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.
In Mozilla Bugzilla #408723, Philringnalda (philringnalda) wrote : | #98 |
*** Bug 422518 has been marked as a duplicate of this bug. ***
Will Nowak (compbrain) wrote : | #99 |
Looks like this is fixed for me with the installation of 3.0~b4+
Daniel Persson (daniel-danielpersson) wrote : | #100 |
It still seems like you can recreate the unwanted behavior by typing fast, or by just entering one character also results in that the item where the mouse is over is highlighted... so for me it is partially fixed only ...
In Mozilla Bugzilla #408723, Jruderman (jruderman) wrote : | #101 |
*** Bug 423875 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #408723, Sylvain Pasche (sylvain-pasche) wrote : | #102 |
*** Bug 424541 has been marked as a duplicate of this bug. ***
Benji York (benji) wrote : | #103 |
Like Daniel Persson, I still see the unwanted behavior. Very irritating.
Alexander Sack (asac) wrote : | #104 |
b5 will have this fix.
Alexander Sack (asac) wrote : | #105 |
forgot to close. we have beta 4 for some time now.
Changed in firefox-3.0: | |
status: | Fix Committed → Fix Released |
sova (minarikmatus) wrote : | #106 |
still appears in inputboxes on webpages when remembering previously submitted text is allowed:
firefox 3.0.0.11
ubuntu 9.04 (jaunty)
kernel Linux 2.6.28-11-generic
GNOME 2.26.1
Changed in firefox: | |
importance: | Unknown → Medium |
*** This bug has been marked as a duplicate of bug 400671 ***