Closed Bug 418343 Opened 16 years ago Closed 16 years ago

Autocomplete results (search and form history) no longer sorted

Categories

(Toolkit :: Form Manager, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla1.9.1b1

People

(Reporter: joseph, Assigned: Gavin)

References

Details

(Keywords: regression, verified1.9.0.4)

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3) Gecko/2008020514 Firefox/3.0b3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3) Gecko/2008020514 Firefox/3.0b3

The search bar is giving results in random order (Not in alphabetical order).

Reproducible: Always

Steps to Reproduce:
1. Go to search bar (CTRL+K)
2. Press down
3. See result order
Actual Results:  
Random order in results

Expected Results:  
Alphabetical order in results
You mean the search engines in the drop-down ? That list can be rearranged in Manage Search Engines (bottom of the menu) - it's the user who determines the order (most important ones at the top for instance).
No, he means the form history results (not suggestions) that appear in the search bar autocomplete when you launch an "empty" query, by just pressing down. These results used to be alphabetical, but now they aren't.
I'm not sure what would have changed here to cause that. I don't see any relevant changes in the search bar frontend, so I imagine it's some nsStorageFormHistory change. Does content form autocomplete have the same problem?
Sorry if I wasn't clear. As Gavin said it is the history results that are no longer sorted alphabetically.

I just checked on Form Autocomplete as well, and it also has the same problem. The history results are in random order as well.
Component: Search → Form Manager
QA Contact: search → form.manager
I'm running into this problem with my Googlebar Lite extension. It seems to me that the autocomplete results are using the insertion order for sorting (newest on the bottom).

Might this indicate that the default sort order for this control has been set to "natural"? I see that the sortDirection property (http://developer.mozilla.org/en/docsXUL:Attribute:sortDirection) provides that choice, along with "ascending" and "descending".
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008061004 Firefox/3.0

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.1pre) Gecko/2008062004 GranParadiso/3.0.1pre

The results are not in alphabetical order, but in chronological order it seems. The newest search items are on the bottom and the oldest on top.

Nevertheless, marking as confirmed based on Gavin's comment that it should be in alphabetical order. 
Status: UNCONFIRMED → NEW
Ever confirmed: true
It is pain that the oldest has been the top.

I made an extension to change this turn. 
https://addons.mozilla.org/en-US/firefox/addon/7826 (In SandBox Login is necessary) for firefox3.0
I'm also noticing this order problem with forms.  It's not just with the search bar.  Every time I enter info into a search bar, it gets added to the end of the list.  I'd like it to be sorted alphabetically like it was in version 2... or at least give us an option to change this somewhere.
Summary: Search Autocomplete Random Order → Autocomplete results (search and form history) no longer sorted
If someone could find a regression range for this bug using builds from ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly , that would be very helpful. (See http://wiki.mozilla.org/QA#What_We_Use for a bit more information on finding regression ranges.)
Just wondering, can't we use the extension that Alice made and just turn it to a patch?
We need to understand why this broke in the first place before trying to work around it. I suspect a change in SQLite, because I don't think any of the relevant form history code has changed, but I could be wrong. Need a regression range to be sure.
I tried the earliest 3.0 alpha and it still had the issue. And going further back went to the Deer Park (1.6) build and apparently it had it too.

Here are the range I got...
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060222 Firefox/1.6a1

to..

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060306 Firefox/1.6a1

I couldn't narrow it down some more because the Win32 installers were crashing within that range.
I only noticed the change when I upgraded to Firefox version 3.  I never had this issue with 2.  Ever since 3, search box entries and form autocompletes appear in order in which they were entered.  I don't know if this is all part of the so-called "frecency" thing, as it's related to the changes in the smart location bar or what, but like I said, it's just a problem in v3.
The work on the Smart Location Bar is most likely what broke this. Since the location bar is a input form but sorted by frequency (most used at top) which the search box and web forms don't keep track of.

IIRC the smart location bar was worked on and planned for v2 but then delayed for v3. So this is maybe why I found the regression range in the v1.6 builds.
Product: Firefox → Toolkit
I really hope this will be fixed soon, because it's just annoying. 
I absolutely love Firefox, if only this bug didn't exist!
This is still not fixed as of 8/31. Please get to it!
Not fixed as of 9/3/2008, please fix this to help keep me sane. Thanks!
@Thomas, Gary, Lady: please stop spamming with useless comments. Of course it's not fixed. if it would have been fixed, the bug's status field would say so. spamming does *not* make a bug getting fixed faster.

range:
firefox-1.6a1.en-US.win32.installer-2006-03-01-07-trunk -> ok
firefox-1.6a1.en-US.win32.installer-2006-03-02-07-trunk -> fails, places landed

=>
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=AviaryBranchTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-03-01&maxdate=2006-03-02&cvsroot=%2Fcvsroot
(i hope i got the module right)

my bet without any coding knowledge: Bug 324918 caused this, proper investigation is needed.
Keywords: qawanted, regression
I see the expected behaviour on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16.
Attached patch patchSplinter Review
As far as I can tell the sorting in the previous implementation was unintentional (it defaulted to returning stuff in alphabetical order, whereas mozstorage returns stuff in insertion order). This explicitly sorts by value.
Assignee: nobody → gavin.sharp
Status: NEW → ASSIGNED
Attachment #336894 - Flags: review?(sdwilsh)
Flags: wanted1.9.0.x?
Keywords: qawanted
OS: Windows XP → All
Hardware: PC → All
Target Milestone: --- → mozilla1.9.1b1
Version: unspecified → Trunk
Attachment #336894 - Flags: review?(sdwilsh) → review+
Comment on attachment 336894 [details] [diff] [review]
patch

r=sdwilsh

Could we maybe get a test for this?  Test would be a bit verbose though..
Comment on attachment 336894 [details] [diff] [review]
patch

Drivers: safe/simple change to fix a commonly reported functional regression from Firefox 2.
Attachment #336894 - Flags: approval1.9.0.3?
I looked into tests for satchel code but ran into the issues in bug 444728 comment 8. Can get a test for this once that problem is figured out.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Doesn't really meet the "wanted" criteria (security, stability, regression from maintenance release) for 1.9.0.x. However, we'll look at the patch later.
Flags: wanted1.9.0.x?
Comment on attachment 336894 [details] [diff] [review]
patch

Approved for 1.9.0.4, a=dveditz for release-drivers
Attachment #336894 - Flags: approval1.9.0.4? → approval1.9.0.4+
STR for verification:
1) Go to google.com
2) first search for "z"
3) then search for "a"
4) return to google.com, and press down arrow in the search textbox to show the autocomplete popup

Expected results: "a" entry shows up first.

With this bug, the "z" entry appeared first (since it was added first).
Keywords: fixed1.9.0.4
mozilla/toolkit/components/satchel/src/nsStorageFormHistory.cpp 	1.22
Verified for 1.9.0.4 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.4pre) Gecko/2008102404 GranParadiso/3.0.4pre. Results are properly in alphabetical order now.

Verified for Trunk with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081024 Minefield/3.1b2pre.
Status: RESOLVED → VERIFIED
Using: Mozilla/5.0 (Windows; U; Windows NT 5.1; da; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4

The search bar and normal form fields now have sorted autocomplete, but if the form field is input for a username, the autocomplete results are not sorted. Is this the same bug or should I file a new one?
Jesper, i'd say file a new one with proper STRs & maybe check if the regression range is the same as in comment 21.
Please file a new one and CC me (the fix is likely the same, just in a different place).
This bug is present again in Firefox 3.6 in forms and search bar...
Firefox 3.6 sorts form history items using a "frecency" algorithm, similar to the one used for the location bar, see bug 370117.
This is not easy to find entries in this order. :-/
Other people request the update of extension Searchbar Autocomplete Order https://addons.mozilla.org/en-US/firefox/addon/7826
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: