Closed
Bug 420446
Opened 17 years ago
Closed 6 years ago
Duplicates make Most Visited useless, we should show only typed in addresses
Categories
(Firefox :: Bookmarks & History, defect, P5)
Firefox
Bookmarks & History
Tracking
()
RESOLVED
INACTIVE
People
(Reporter: ojab, Unassigned)
References
(Depends on 1 open bug)
Details
Attachments
(3 files)
(deleted),
image/png
|
Details | |
(deleted),
image/jpeg
|
Details | |
(deleted),
image/png
|
beltzner
:
ui-review+
|
Details |
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.
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.
Updated•17 years ago
|
Component: Bookmarks → Places
QA Contact: bookmarks → places
Comment 3•16 years ago
|
||
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.
Comment 4•16 years ago
|
||
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...
Comment 6•16 years ago
|
||
Regarding comment #4 and comment #6.
From Epiphany ChangeLog.
2003-03-24 Xan Lopez <xan@masilla.org>
...
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.
Comment 9•16 years ago
|
||
(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.
Comment 10•16 years ago
|
||
(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.
Comment 11•16 years ago
|
||
(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.
Comment 12•16 years ago
|
||
I also have this problem, and its really important that it will be fixed.
Comment 13•16 years ago
|
||
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
Updated•16 years ago
|
Summary: Duplicates in Most visited smart Bookmarks makes it useless → Duplicates in Most Visited smart bookmark makes it useless
Comment 14•16 years ago
|
||
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
Updated•16 years ago
|
Target Milestone: --- → Firefox 3.1
Comment 15•16 years ago
|
||
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.
Updated•16 years ago
|
OS: Linux → All
Hardware: PC → All
Comment 16•16 years ago
|
||
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)
Updated•16 years ago
|
Attachment #339247 -
Flags: ui-review?(beltzner) → ui-review+
Comment 17•16 years ago
|
||
Comment on attachment 339247 [details]
change to typed only and solving redirects
ui-yarrrr = beltzner
Updated•16 years ago
|
Flags: wanted-firefox3.1+
Flags: blocking-firefox3.1?
Flags: blocking-firefox3.1-
Priority: -- → P1
Comment 20•16 years ago
|
||
To be clear, I really want to see this fixed, but Dietrich convinced me it's not a hard blocker.
Updated•16 years ago
|
Version: unspecified → Trunk
Comment 21•16 years ago
|
||
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
Comment 22•16 years ago
|
||
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
Comment 23•16 years ago
|
||
Can we not leverage the logic / fix from bug 426864?
Comment 24•16 years ago
|
||
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.
Comment 25•16 years ago
|
||
(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
Updated•15 years ago
|
Target Milestone: Firefox 3.6a1 → ---
Updated•15 years ago
|
Flags: wanted-firefox3.5+ → wanted-firefox3.6+
Comment 26•15 years ago
|
||
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
Updated•15 years ago
|
Assignee: mak77 → nobody
Status: ASSIGNED → NEW
Updated•9 years ago
|
Priority: P1 → --
Updated•9 years ago
|
Priority: -- → P4
Updated•8 years ago
|
Priority: P4 → P5
Comment 27•6 years ago
|
||
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: 6 years ago
Resolution: --- → INACTIVE
You need to log in
before you can comment on or make changes to this bug.
Description
•