258107 - Location bar should sort based on order visited

Status: RESOLVED WONTFIX

(Firefox :: Address Bar, defect)

Description

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

In seamonkey, if I type "yahoo.com", then "google.com", the order is:
google.com
yahoo.com
If I then type "yahoo.com" again, the order is:
yahoo.com
google.com

Firefox 0.9.3 doesn't show this behavior.

Comment 1

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

->somebody else

<CTho> mrbkap:
http://lxr.mozilla.org/aviarybranch/source/xpfe/browser/resources/content/sessionHistoryUI.js#267
so seamonkey has a separate RDF for the URL dropdown which is manipulated
independently of the stuff messed with by markPageAsTyped? 
<mrbkap> CTho: that's what it looks like (all that stuff with 'entries')
<CTho> oh.  so that means fixing it in aviary would involve a LOT of work 
<CTho> (since all the other poitns that deal with the dropdown would need to be
updated)
<mrbkap> CTho: You'd probably have to port the Seamonkey stuff over.
<mrbkap> CTho: yeah, sort of...I don't know the code though

Comment 2

[chris hofmann]

may try to get this, or at least more analysis before final.

Comment 3

[Troodon]

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

Comment 4

[deleteaccount]

I took away my vote for this, because I realized it might result in the subpages
of a web site being at the top of the list before the web site home page, which
would mean almost always extra arrowing down.

Is there a way to delete a url from the location bar "cache", for web sites no
longer of interest?  I tried various things but couldn't do this.

Comment 5

[deleteaccount]

Sorry, I then read the bug report of which this is a duplicate and saw
shift-delete.  Not obvious interface, I had rightclicked on the item, expecting
that to bring up a menu, instead it acted as a go-to.

Comment 6

[Matthew deStwolinski]

I would suggest that the order should not be determined by what was VISITED, but
by what was TYPED into the location bar or SELECTED from the drop down of the
location bar.  The entries that are there to begin with are only ones that were
typed at some point...it's not a general history area of places you've visited.
 To keep consistent with that model, the ordering should only be affected by
using the location bar to go to a link.  If the typed URL is new, it should be
added to the top of the list (as it currently is).  If an existing URL is
selected, it should move to the top of the list (that would be the only new
functionality).  That way, the list gives you easiest access to the things
you've already used it for.

In the example of subpages being listed above a site's home page, the subpage
would only exist in the list if user had typed its entire URL in directly at
some point.  And it would only be listed above the home page if it had been
entered or selected more recently than the home page.  

A personal example...it's very consistent with some links that I use.  I first 
go to a home page, then navigate to a subpage I really care about.  I copy the
URL, leave the page, and paste the subpage URL back in so that it will be there
on its own.  The when accessing that site, I almost always select the subpage URL.

This is, by the way, the exact behavior of recent versions of IE.  I do love the
  shift-delete ability to delete individual entries (even if it wasn't intuitive
to discover.)

Sorry for the length.

Comment 7

[Andriy Gapon]

as an author of the fix for a similar problem in mozilla suite, I must say that
the code in firefox is quite different, but if I understand it correctly the
behavior can be improved and maybe in even better way than "most recently
typed/selected on the top". Baiscally,
nsGlobalHistory::AutoCompleteTypedSearch() which is used to construct a list of
manually typed urls (which is apparently used as location bar drop-down history
list) can borrow url sorting code from its brother-method
nsGlobalHistory::AutoCompleteSearch(), so that urls are sorted according to a
quite complex algorithm that takes into account many properties like number of
visits, site vs. page, manually typed url, etc. While copying from a temporary
result set into a final result set, list size limit can also be enforced - it is
unlimited now as you can easily verify.
I am not sure if nsGlobalHistory::AutoCompleteTypedSearch() is used for anything
else in addition to constructing urlbar history, somebody with architectural
knowledge should be able to easily verify that.
I've applied the described fix here and the result looks very attractive :-)

Comment 8

[Andriy Gapon]

Attachment: sorting patch

patch to illustrate sorting fix (without size limit)

Comment 9

[Andriy Gapon]

Attachment: better sorting patch

This patch implements sorting closer to classical i.e. based on last visited
time, this way most recently visited urls will be on the top. One deviation
from classic behavior (for better or for worse) is that classic sorting
promotes a url to the top only if it is typed or selected in location bar, with
this patch a url is also promoted if it is visited in any other way e.g. this
includes visited by a link from another page, visited from a bookmark etc.

Comment 10

[Clausi]

I don't understand how to apply this patch! Can you HELP ME PLEASE

Comment 11

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

(In reply to comment #10)
> I don't understand how to apply this patch! Can you HELP ME PLEASE

Get the source code and a working build environment, download the patch to
somefilename.diff, run "patch -p0 -i somefilename.diff" from the mozilla/
directory, and recompile Firefox.  You'll need a few hours and a few hundred MB
of disk space.  Alternately, wait for the patch to get reviewed and checked in,
then download the next nightly build (or if you're more patient or want a
browser that's more likely to work properly, the next release build).

Comment 12

[Sven Rose]

(In reply to comment #11)
> (In reply to comment #10)
> > I don't understand how to apply this patch! Can you HELP ME PLEASE
> 
> Get the source code and a working build environment, download the patch to
> somefilename.diff, run "patch -p0 -i somefilename.diff" from the mozilla/
> directory, and recompile Firefox.  You'll need a few hours and a few hundred MB
> of disk space.  Alternately, wait for the patch to get reviewed and checked in,
> then download the next nightly build (or if you're more patient or want a
> browser that's more likely to work properly, the next release build).

The last entry was from January and nothing has changed!
I awaited a modified version but even in the 1.0.4 nightlies there's still the
same problem. What a pity...

Comment 13

[scotthabs]

I agree with comment #6 from Matthew, which recommends that the sort on the
location bar should bring only the most recently TYPED address, or SELECTED from
the drop down of the location bar, to the top of the address bar list.

Comment 14

[Alan Erickson]

(In reply to comment #11)
> (In reply to comment #10)
> > I don't understand how to apply this patch! Can you HELP ME PLEASE
> 
> Get the source code and a working build environment, download the patch to
> somefilename.diff, run "patch -p0 -i somefilename.diff" from the mozilla/
> directory, and recompile Firefox.  You'll need a few hours and a few hundred MB
> of disk space.  Alternately, wait for the patch to get reviewed and checked in,
> then download the next nightly build (or if you're more patient or want a
> browser that's more likely to work properly, the next release build).

 Shouldn't have this been included in 1.05 / 1.06?   I would think that that
would easily qualify as a release build.

Comment 15

[info665-s1]

I agree this should have been fixed long time ago yet.
Make it to sort the list like in Internet Explorer.

Comment 16

[Reed Loden [:reed]]

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

Comment 17

[Reed Loden [:reed]]

(In reply to comment #9)
> Created an attachment (id=177153) [edit]
> better sorting patch
> 
> This patch implements sorting closer to classical i.e. based on last visited
> time, this way most recently visited urls will be on the top. One deviation
> from classic behavior (for better or for worse) is that classic sorting
> promotes a url to the top only if it is typed or selected in location bar, with
> this patch a url is also promoted if it is visited in any other way e.g. this
> includes visited by a link from another page, visited from a bookmark etc.

Please update your code to latest CVS, resubmit, and request review and superreview for it by setting those flags to '?'. If you do not request those flags, none of the developers will know to check out your patch.

If you require assistance doing this, please ask.

Comment 18

[Reed Loden [:reed]]

(In reply to comment #17)

> Please update your code to latest CVS...

timeless just pointed out that this patch is not a CVS diff. Please resubmit it as a diff from CVS as the code constantly changes. As I said earlier, if you require assistance with this, please ask.

You -should- be able to set r?/sr? yourself (as timeless and I tested it), but if you encounter problems, please ask.

Also, timeless says you should cache closure->history locally. :)

Comment 19

[Andriy Gapon]

Reed,

normally this probably wouldn't be a big problem for me, but, unfortunately, I am very time-constrained now. I'd appreciate greatly if someone did this - I really want to see this patch merged into firefox, but I'll be able to do the update in a month or so, not sooner.

Comment 20

[Reed Loden [:reed]]

(In reply to comment #19)
> normally this probably wouldn't be a big problem for me, but, unfortunately, I
> am very time-constrained now. I'd appreciate greatly if someone did this

ok, I understand. I'll see if I can find somebody to work on this bug.

Comment 21

[Andrew Schultz]

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

Comment 22

[ksc218]

(In reply to comment #9)
> this patch a url is also promoted if it is visited in any other way e.g. this
> includes visited by a link from another page, visited from a bookmark etc.

(In reply to comment #17)
> Please update your code to latest CVS, resubmit, and request review and
> superreview for it by setting those flags to '?'. If you do not request those
> flags, none of the developers will know to check out your patch.
> If you require assistance doing this, please ask.


Whoever updates the code could someone please change it so that only sites typed or selected will go to the top of the list as Internet Expolorer does.

Comment 23

[Jesse Ruderman]

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

Comment 24

[Dietrich Ayala (:dietrich)]

Attachment: updated version of the previous patch - patched against branch.

if i read the comments correctly, it seems that this patch just needed to be created in the proper format. this attachment is a cvs diff against the 1.8 branch (do i also need to create one for trunk?)

i tested it against the repro steps provided in the initial bug comments, and it solved that problem.

Comment 25

[Mike Connor [:mconnor]]

Comment on attachment 213431 [details] [diff] [review]
updated version of the previous patch - patched against branch.

clearing flag for now, doesn't matter with places

Comment 26

[Mike Connor [:mconnor]]

-> beta1

Comment 27

[Arris]

I known this is no major, or security Bug, but please fix it someone; Because im tired of to tell the people: "Yes i know that Mozilla 1.xx and Internet Explorer can do this, but Firefox 1.5.x cant"
And imho in couse of usabillity this IS a major bug!
Please fix it.
Please!
Please!
Please!

Comment 28

[Dietrich Ayala (:dietrich)]

Attachment: branch patch

Updated to work on branch. Should this go on trunk as well, for non-places builds?

Comment 29

[Mike Connor [:mconnor]]

Comment on attachment 226523 [details] [diff] [review]
branch patch

r=me, looks good

a=me as well, since this can't really bake on trunk, even though it should still land there.

Comment 30

[Mike Connor [:mconnor]]

pushing out non-critical-path bugs to b2

Comment 31

[Dietrich Ayala (:dietrich)]

Checked-in and then reverted due to Ts failure on pacifica-vm on branch. The first few Ts runs would be ok, and then the rest would fail, with no information in the log. I'm setting up a tinderbox on windows, and will see if I can reproduce there once I get some time.

Comment 32

[Dietrich Ayala (:dietrich)]

I haven't had time to look into this, and probably won't have time before beta 2 freeze. It caused Ts failure on one windows tinderbox and not another (and no other platforms), and I do not know why.

Comment 33

[Adam Guthrie]

I discussed this with dietrich on IRC and he decided that he'd give this patch another go to see if it would regress Ts again. So if someone could check this in again for dietrich and keep an eye on Ts, that would be great.

Personally, I don't see how this could affect Ts unless it caused rebuilding of the database on startup or something.

Comment 34

[kl]

hi mike,

will this very annoying bug we wait for more the 2 years to be fixed make it into firefox2? For those who wait for a resolution a short status would be helpful.

thanks,

klaus

Comment 35

[Mike Connor [:mconnor]]

At this time, it looks like we're not going to get a fix that doesn't cause regressions in the Firefox 2 timeframe.  It'd be great to get a fix, but there was bigger fish to fry at the time.

Comment 36

[sparky]

this is amazing.  that's all I have to say.  i've been waiting for such a long time for this to be fixed, but no.  theres something seriously f-ed up with the mozilla/firefox process when it takes more than TWO YEARS for something like this to be fixed (and it still isn't).  enough is enough, i'm switching to something different.  something where broken stuff gets fixed.

Comment 37

[Aneesha]

The Target milestone is long gone. When will this bug be fixed and merged?

Comment 38

[Aneesha]

The affected OS includes Linux. 

Versions affected - all versions after 0.9.3.

Comment 39

[Steve Brecht]

Today, 4 years and 4 months after I submitted another "Bug" I saw it get marked as resolved.  IMO this one is an even more important issue.  Can we at least aim for 4 years and 3 months? :)

In all seriousness I really fail to grasp how this isn't solved already.  There has to be something really odd about Ff's internal structure that you can't sort a basic list of items on when it was last accessed.

Comment 40

[2cows]

I'm very sad about this stupid bug. So i moved back to IE 7. 

Comment 41

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

(In reply to comment #39)
> Today, 4 years and 4 months after I submitted another "Bug" I saw it get marked
> as resolved.  IMO this one is an even more important issue.  Can we at least
> aim for 4 years and 3 months? :)
> 
> In all seriousness I really fail to grasp how this isn't solved already.  There
> has to be something really odd about Ff's internal structure that you can't
> sort a basic list of items on when it was last accessed.

Please read the bugzilla etiquette guidelines.

(In reply to comment #40)
> I'm very sad about this stupid bug. So i moved back to IE 7.

Good.  One fewer person spamming bugs.

Comment 42

[jsimlo]

I suggest an option in the preferences (e.g. browser.urlbar.sortBy) which would decide, which sorting algorithm should be used. There are several possibilities, all of them wanted by someone else.

Second, I suggest an option to sort the list alphabetically. This would result in behaviour similar to the old IExplorer. When I typed "moz" there, the offered list was:

- mozilla.com/
- mozilla.com/firefox
- mozilla.com/thunderbird
- ....

In conjuction with preference browser.urlbar.autoFill = true this offered the user a way to type only the first letters of each part of the address and let the browser autocomplete the rest of the next part for him. Yes, it required to type several times to complete a long url, but it is what IExplorer users are used to anyway.

Comment 43

[Aneesha]

(In reply to comment #42)
> I suggest an option in the preferences (e.g. browser.urlbar.sortBy) which would
> decide, which sorting algorithm should be used. There are several
> possibilities, all of them wanted by someone else.
> 
> Second, I suggest an option to sort the list alphabetically. This would result
> in behaviour similar to the old IExplorer. When I typed "moz" there, the
> offered list was:
> 
> - mozilla.com/
> - mozilla.com/firefox
> - mozilla.com/thunderbird
> - ....

That already happens. This bug is not about what way the list is sorted when you type. It is for the list that is displayed when u click on the dropdown button on the right in the address bar to choose to open a pre-entered URL. That list ought to be sorted by last visited, just like in IE. I hope you understand what I am trying to say..

Comment 44

[jsimlo]

> > Second, I suggest an option to sort the list alphabetically. This would
> > result in behaviour similar to the old IExplorer. When I typed "moz"
> > there, the offered list was:
> > 
> > - mozilla.com/
> > - mozilla.com/firefox
> > - mozilla.com/thunderbird
> > - ....
> 
> That already happens. This bug is not about what way the list is sorted when
> you type. It is for the list that is displayed when u click on the dropdown
> button on the right in the address bar to choose to open a pre-entered URL.
> That list ought to be sorted by last visited, just like in IE. I hope you
> understand what I am trying to say..


Well, maybe I just do not know, what option to set. Right now, I have tried with Firefox 2.0 and typed "mozil" into the addressbar. I awaited Firefox to autocomplete it to "mozilla.com/" which is the first url in my history, when sorted alphabetically. Instead it autocompleted it to "mozilla.com/firefox".
I used "browser.urlbar.autoFill = true".

Shall I start a new feature request about "alphabetically sorted autocomplete inlocation bar" or does it belong to this thread?

jsimlo

Comment 45

[Aneesha]

(In reply to comment #44)
> Well, maybe I just do not know, what option to set. Right now, I have tried
> with Firefox 2.0 and typed "mozil" into the addressbar. I awaited Firefox to
> autocomplete it to "mozilla.com/" which is the first url in my history, when
> sorted alphabetically. Instead it autocompleted it to "mozilla.com/firefox".
> I used "browser.urlbar.autoFill = true".
> 
> Shall I start a new feature request about "alphabetically sorted autocomplete
> inlocation bar" or does it belong to this thread?

Do you mean inline auto-complete? Firefox does not have that yet. It only gives auto-complete suggestions from what I know. 

I think it would be a separate feature, maybe it is already logged. You can try searching for the same. Hope that helps. 

Comment 46

[(not reading, please use [e-mail] instead)]

would be great to get this into 2.0.0.1, assuming we can confirm the Ts regression was just a red herring.

Comment 47

[(not reading, please use [e-mail] instead)]

a regression, but not a blocker for 2.0.0.1.

Comment 48

[Aneesha]

(In reply to comment #47)
> a regression, but not a blocker for 2.0.0.1.
> 

Taking into account that Firefox 2.0.0.1 is already out, shouldn't that comment be changed?

Comment 49

[Christian Junghans]

Is this "Bug" fixed in Firefox 3.0 Alpha 2, now?

Comment 50

[Dietrich Ayala (:dietrich)]

(In reply to comment #49)
> Is this "Bug" fixed in Firefox 3.0 Alpha 2, now?
> 

I tested with a trunk build from today, and yes, the behavior described in comment #1 is present.

Comment 51

[j.j.]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007101504 Minefield/3.0a9pre

This works for me on trunk.
Can someone close this bug?
(And can we have this on branch?)

Comment 52

[Dietrich Ayala (:dietrich)]

Places-based autocomplete recently implemented a "frecency" algorithm for autocomplete sorting, detailed a bit more here:

http://mxr.mozilla.org/seamonkey/source/toolkit/components/places/src/nsNavHistoryAutoComplete.cpp#43

However, note that "frecency" doesn't sort *exclusively* by order visited, which is what this bug is asking for, so this bug is sounding like WONTFIX at this point. Reporter (and the various commenters), please try out a recent Fx3 build and see if the new algorithm meets your needs.

If you want pluggable sorting algorithms, I'd recommend building a Firefox extension.

Comment 53

[Reed Loden [:reed]]

Heh, frecency, eh... Interesting combination between frequency and recently.

Comment 54

[scratch]

i think this is WONTFIX.

Comment 55

[David Jameson]

This bug annoys me every day and it really needs fixed.

Comment 56

[j.j.]

David, see comment 51. Location Bar behaviour changed completely on trunk (Fx3). Fx2 will not be changed.

So this bug can be closed as WFM or WONTFIX, depending on personal perspective.

Comment 57

[David Jameson]

I don't understand - has this bug been fixed in firefox 3 or will it not be fixed?  Comment 51 isn't clear and the comments after suggest that it is NOT fixed. If it has been fixed, the bug should be marked FIXED and closed.

Comment 58

[Adam Kowalczyk]

David, Location Bar autocomplete has been redesigned from scratch in Firefox 3. It uses a much more elaborate sorting algorithm and order visited is only one of many criteria.

We certainly aren't going to give up frecency and go back to sorting strictly by order visited, which is what this bug is about. I'm going ahead and marking it as WONTFIX.

Comment 59

[Reed Loden [:reed]]

(In reply to comment #58)
> We certainly aren't going to give up frecency and go back to sorting strictly
> by order visited, which is what this bug is about. I'm going ahead and marking
> it as WONTFIX.

Resolving a bug as WONTFIX is up to module owners and peers only. See http://www.mozilla.org/quality/help/bugzilla-privilege-guide.html#wontfix for details.

Comment 60

[Adam Kowalczyk]

Reed, I took the freedom to do it, because in comment #52 Dietrich suggested it should be WONTFIX if we use "frecency". At this point "frecency" is definitely staying, so it seemed obvious.

Comment 61

[j.j.]

(In reply to comment #59) 
> Resolving a bug as WONTFIX is up to module owners and peers only.

Than they should do that. The "reopend" state makes confusion complete now.  

Comment 62

[Dietrich Ayala (:dietrich)]

(In reply to comment #57)
> I don't understand - has this bug been fixed in firefox 3 or will it not be
> fixed?  Comment 51 isn't clear and the comments after suggest that it is NOT
> fixed. If it has been fixed, the bug should be marked FIXED and closed.
> 

David, please re-read comment #52. Firefox 3 has completely overhauled the old location bar behavior. More information in the links below:

http://mxr.mozilla.org/seamonkey/source/toolkit/components/places/src/nsNavHistoryAutoComplete.cpp#45

http://developer.mozilla.org/en/docs/Places:Awesomebar

(In reply to comment #59)
> Resolving a bug as WONTFIX is up to module owners and peers only. See
> http://www.mozilla.org/quality/help/bugzilla-privilege-guide.html#wontfix for
> details.
> 

I'm not a peer or module owner, maybe Gavin will mark this WONTFIX?

Comment 63

[David Jameson]

Okay, that clears things up - thanks. I haven't used firefox 3 yet, but I agree that this bug should be closed as it doesn't apply any more. If people are unhappy with the new behaviour then we can open a new bug.

Comment 64

[Reed Loden [:reed]]

(In reply to comment #62)
> I'm not a peer or module owner, maybe Gavin will mark this WONTFIX?

You're the submodule owner of the code that now controls the location bar (Places), so you're welcome to WONTFIX this bug.

Comment 65

[David Jameson]

I've tried firefox 3, and the location bar is still useless for me. When I click on the bar I want to see the sites I most recently visited, but instead it appears to be a random collection of some recently visited sites and others that I haven't visited in a long time. I understand the algorithm used, and I'm sure it works properly, but it just doesn't give a very useful result, at least for me.

We really need the option to sort the list purely by date last visited. IE does this, and it is much more useful.

Have you done a user poll to find out the % of people who want the new behaviour versus order visited?

Regarding my previous comment: I see that this bug isn't actually for firefox 2 so we don't need to open a new bug, we just need to get this re-opened, unless you can give us a reason why this bug is WONTFIX.

Comment 66

[j.j.]

See also bug 430355