635795 - Off-by-one auto-selection in location-bar autocomplete drop-down list: 2nd item is highlighted.

Status: RESOLVED FIXED

(Camino Graveyard :: Location Bar & Autocomplete, defect)

Description

[sci-fi]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en; rv:1.9.2.15pre) Gecko/20110221 Camino/2.1a2pre (like Firefox/3.6.15pre)
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en; rv:1.9.2.15pre) Gecko/20110221 Camino/2.1a2pre (like Firefox/3.6.15pre)

Hi,

I have been noticing this in the past few nightly official builds.

While typing a URL in the location bar, the list of URLs being shown in the drop-down list, of the autocomplete choices, is off by one:  The 2nd item is usually being automatically highlighted for the selection.  In most of my cases, the 1st item would be the "best choice" but is not selected; it requires an up-arrow to be hit, forcing a disruption of typing sequence/habit.

It seems some work is recently being done in this area -- the response-time etc are much much better now, however it's having to suddenly upset our typing habits.  ;)

Thank you.


Reproducible: Always

Steps to Reproduce:
1. Type a partial known URL in the location bar, i.e. something that will cause a goodly list to drop-down via autocompletion.
2. Note that the 2nd ("wrong") item in the list is selected.
3. To select the 1st ("best") item, an up-arrow key needs to be hit.

Actual Results:  
I usually hit the "enter" key when there is enough letters inside the location bar to select the "best" autocompleted item.  Currently with this "new" bug, we end up selecting the 2nd item which is not the correct expected one, thus going to the wrong location.


Expected Results:  
In earlier builds, we would usually go to the "first=best" autocompleted URL in the drop-down list.

I'm unsure exactly when this action has changed (e.g. which nightly build started showing the problem), but it seems to be related to recent work done in the location-bar autocompletion arena.

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: Select the right row with inline autocomplete

Ah, the key here is that you have the "inline autocomplete" hidden pref set; this is easily reproducible once we know that.  It's almost certainly a regression from bug 548464.

Stuart, I think the change http://hg.mozilla.org/camino/diff/d81070ade302/src/browser/AutoCompleteTextField.mm#l1.473 is likewise wrong, but I also think that's dead code since MAAttachedWindow, just like scrollPageUp: and scrollPageDown: (unless bug 506733 will make Home/End do something).

This patch just fixes the immediate inline issue, but I can roll up whatever the right fix ends up being for those selectors.

Comment 2

[Stuart Morgan]

Comment on attachment 514112 [details] [diff] [review]
Select the right row with inline autocomplete

Whoops! sr=smorgan.

If we do go back to titles at some point we should do something smarter than hard-code 1, so this won't happen again.

Comment 3

[sci-fi]

Hi,

For the record ---

I believe these (and several more "hidden" options) are set with an add-on prefpane called "Settings Plus v1.2" made by Mr Rafael L Klaus available at http://rafaelklaus.com/settings-plus-prefpane, so I imagine many Camino users might spot this particular bug if released to an official package.

I checked my about:config list for the urlbar settings.
It shows:
browser.urlbar.autoFill
	user set
	boolean	true (whole line in bold)
browser.urlbar.autocomplete.enabled
	default
	boolean	true (in plain)
browser.urlbar.clickAtEndSelects
	default
	boolean	false (in plain)

Thank you-all for acting so quickly.  :)

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Landed as http://hg.mozilla.org/camino/rev/b6cab1eb7ae3

(In reply to comment #1)
> Stuart, I think the change
> http://hg.mozilla.org/camino/diff/d81070ade302/src/browser/AutoCompleteTextField.mm#l1.473
> is likewise wrong, but I also think that's dead code since MAAttachedWindow,
> just like scrollPageUp: and scrollPageDown: (unless bug 506733 will make
> Home/End do something).

I totally missed that this diff was Dan's initial rewrite, not Stuart's recent rewrite; that makes the regression (and how bizarre the diff seemed, in that light) make more sense.  I'll spin off the dead? selectors into bug 635827.

(In reply to comment #3)
> I believe these (and several more "hidden" options) are set with an add-on
> prefpane called "Settings Plus v1.2" made by Mr Rafael L Klaus available at
> http://rafaelklaus.com/settings-plus-prefpane, so I imagine many Camino users
> might spot this particular bug if released to an official package.

We also document this one on our own website ;-) [e-mail], thanks for reporting this; it will be fixed in tomorrow's nightly.

> browser.urlbar.clickAtEndSelects
>     default
>     boolean    false (in plain)

FWIW, this pref does absolutely nothing in Camino.  I'm not sure if the current Settings Plus still tries to set it or not, but we advised Rafael it did nothing and he shouldn't expose UI for it.