Closed Bug 420446 Opened 13 years ago Closed 3 years ago
Duplicates make Most Visited useless, we should show only typed in addresses
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9b4pre) Gecko/2008022921 Minefield/3.0b4pre Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9b4pre) Gecko/2008022921 Minefield/3.0b4pre See the attachment. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Why so much?
I'm guessing these have unique urls. I'm not sure of an easy way to deal with this, dynamic content like google reader will generate many unique urls for what is essentially the same page/app.
Component: Bookmarks → Places
QA Contact: bookmarks → places
I'm seeing the same with FF 3.0 rc1. The URLs are indeed unique, but regularly visiting a site like google reader makes the "most visited" feature completely useless. Also looks to be a DUP of bug 430583.
This bug/feature doesn't exist in Epiphany browser. Someone should take a look at their source code to see what's the right way to do it...
Regarding comment #4 and comment #6. From Epiphany ChangeLog. 2003-03-24 Xan Lopez <email@example.com> ... Add a "Most Visited" topic, featuring the 10 most visited bookmarks. Now special topics are bold too. I infer from this Epiphany "Most Visited" is simply different since it doesn't mine history. Much easier to keep track if you're only counting hits on specific bookmarks.
(In reply to comment #7) > Much easier to keep track if you're only counting hits on specific bookmarks. Then how about applying a simple logic like this: When calculating the "Most visited" list, add a new entry only if an entry from the same domain does not already exists higher up in the list. This logic can the default logic, with a user selectable switch to use the old logic.
(In reply to comment #8) > Then how about applying a simple logic like this: When calculating the "Most > visited" list, add a new entry only if an entry from the same domain does not > already exists higher up in the list. This logic can the default logic, with a > user selectable switch to use the old logic. That won't do the magic, since there are some common sites were few sites with high rating sits on the same domain. For example - www.google.com/mail and www.google.com/reader - If we are visiting both on a daily basis (and we are!), we want them to appear on that list.
(In reply to comment #9) > That won't do the magic, since there are some common sites were few sites with > high rating sits on the same domain. For example - www.google.com/mail and > www.google.com/reader - If we are visiting both on a daily basis (and we are!), > we want them to appear on that list. > Maybe the term "domain" is a little confusing here. What I meant to say is that everything between the "://" and the first following "/" should be compared. The official term for this part of the URL is "authority" (see RFC2396). For the above example, using "reader.google.com" and "mail.google.com" would give the user 2 entries in the list. I know that this will not work for some people, that's why I suggested adding a user selectable switch to choose between the two options.
(In reply to comment #10) > For the above example, using "reader.google.com" and "mail.google.com" would > give the user 2 entries in the list. You right about mail.google.com, but keep in mind that Google Reader sits at https://www.google.com/reader/view/, and so is most of Google other products.
I also have this problem, and its really important that it will be fixed.
IIRC there is another bug about this, however since i can't find it now i'm confirming this. The problem are unique urls and for sure Most Visited needs some love to be useful, mine too is full of webmail links...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Multiplying sites in Most visited → Duplicates in Most visited smart Bookmarks makes it useless
Summary: Duplicates in Most visited smart Bookmarks makes it useless → Duplicates in Most Visited smart bookmark makes it useless
well i think we should change "most visited" to "most visited typed-in", doing a change under the hood. i would not change the "most visited" title, it's still most visited, only reporting some more useful data, but will ask an ui-review on that.
Assignee: nobody → mak77
Status: NEW → ASSIGNED
Summary: Duplicates in Most Visited smart bookmark makes it useless → Duplicates make Most Visited useless, we should show only typed in addresses
My top most visited places are: http://www.bbc.co.uk/iplayer/ http://www.bbc.co.uk/iplayer http://bbc.co.uk/iplayer They all point to exactly the same place (unless there's a technical reason why they're different) and so should be kept as one item, not three.
This is the change i see using the patch in bug 428690 this is the Most Visited smart bookmark showing only typed addresses and solving redirects (this means that if A -> B -> C we show C) as you can see this is much more useful, before my smart query was full of webmail redirects, while now i get some useful result, only one link to gmail since i've typed it initially and then i go there often, a link to a bugzilla search i use often and so on. Imho the change would not require string changes, it's still a most visited websited list, even if limited to TRANSITION_TYPED pages
Attachment #339247 - Flags: ui-review?(beltzner)
Attachment #339247 - Flags: ui-review?(beltzner) → ui-review+
Comment on attachment 339247 [details] change to typed only and solving redirects ui-yarrrr = beltzner
tranported blocking request from bug 468434.
Priority: -- → P1
To be clear, I really want to see this fixed, but Dietrich convinced me it's not a hard blocker.
well i fix my problem with the Speed dial add-on but i do miss using the "Most visited" i'm to lazy to chek if 3.2a1 does the same on clean install on system with no FF at all :D
we need to better discuss on options for querying typed visits, having a better history table and a transition type option to query would be starting point. Sadly due to that, not going to make 3.1 at this stage.
Target Milestone: Firefox 3.1 → Firefox 3.2a1
Can we not leverage the logic / fix from bug 426864?
Probably can't really use bug 426864 stuff as it accesses places directly whereas Smart Bookmarks use the place: URI to query history/bookmarks/both while specifying how many and in what order to sort them. I'm not super familiar with nsINavHistoryQueryOptions, but we might need to add an attribute like "onlyTyped" similar to "includeHidden". How did you do that mockup Marco? I don't see any simple way of getting at pages with TRANSITION_TYPED visits easily right now. Alternatively, if we just showed the most frecent pages instead of most visited (probably still just call it most visited), it would probably "do the right thing" as typed visits get big bonuses already.
(In reply to comment #24) > How did you do that mockup Marco? I don't see any simple way of getting at > pages with TRANSITION_TYPED visits easily right now. that mockup is a real life screenshot indeed based on the patch i have in bug 428690. That patch was indeed adding a onlyTyped option, but then i thought it would be far better having a way to query the transition type instead in a way like place:transition=1&transition=2&... like we do for folders, so that would replace onlyTyped with place:transition=TYPED. That will also allow many other queries like downloads and so on. but the transition query path is probably going to 3.2... instead i think we can take the redirects cleanup part of the same bug, that will still reduce a bit cluttering in the smart query removing redirects often used by webmail. > Alternatively, if we just showed the most frecent pages instead of most visited > (probably still just call it most visited), it would probably "do the right > thing" as typed visits get big bonuses already. i thought about that, but there are 2 problems: 1. frecency is still not exposed as a sorting option (bug 411591) 2. that would make most visited very similar to the locationbar results (well when i was thinking this the dropdown was not showing only typed) 3. webmails could still have an high frecency being visited often
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h". In Thunderbird 3.0b, you do that as follows: Tools | Message Filters Make sure the correct account is selected. Click "New" Conditions: Body contains places-to-b-and-h Change the action to "Delete Message". Select "Manually Run" from the dropdown at the top. Click OK. Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter. Gerv
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.