Closed
Bug 412217
Opened 17 years ago
Closed 16 years ago
treat TRANSITION_DOWNLOAD like we treat TRANSITION_EMBED visits
Categories
(Firefox :: Bookmarks & History, defect, P4)
Firefox
Bookmarks & History
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: sspitzer, Unassigned)
References
Details
treat TRANSITION_DOWNLOAD like we treat TRANSITION_EMBED visits
right now, we only partially do this. but for global frecency, see bug #394038, I think we need to finish the job.
for example:
>+
>+ // only increment the visit_count if the transition was not EMBED
>+ // XXX what about TRANSITION_DOWNLOAD?
>+ if (aTransitionType != TRANSITION_EMBED)
>+ trueVisitCount++;
as dietrich points out: "a download is fairly different from a visit"
In the example above, I think we need to do:
>+ // only increment the visit_count if the transition was not EMBED
>+ // XXX what about TRANSITION_DOWNLOAD?
>+ if (aTransitionType != TRANSITION_EMBED && aTransitionType != TRANSITION_DOWNLOAD)
>+ trueVisitCount++;
Other examples would be to switch to from "NOT IN (0,4)" to "NOT IN(0,4,7)"
note, when calculating frecency, I already treat download visits like embed visits. from the patch for firefox.js:
>+pref("browser.frecency.embedVisitBonus", 0);
>+pref("browser.frecency.downloadVisitBonus", 0);
Reporter | ||
Comment 1•17 years ago
|
||
perhaps dietrich can work this into bug #394038
Flags: blocking-firefox3?
Updated•17 years ago
|
Flags: blocking-firefox3? → blocking-firefox3+
Updated•17 years ago
|
Assignee: nobody → sdwilsh
Whiteboard: [needs patch]
Comment 3•17 years ago
|
||
(In reply to comment #2)
> dietrich, is this done?
I don't think so. I'll find out by tonight?
Comment 4•17 years ago
|
||
not done
related: bug 412219.
Updated•17 years ago
|
Priority: P3 → P4
Comment 5•17 years ago
|
||
Not blocking on this bug for final ship. Would take a safe enough patch if one comes through.
Flags: wanted-firefox3+
Flags: blocking-firefox3-
Flags: blocking-firefox3+
Comment 6•17 years ago
|
||
partly implemented for visit_count
Comment 7•16 years ago
|
||
Is this bug still valid?
Comment 8•16 years ago
|
||
(In reply to comment #7)
> Is this bug still valid?
probably we need a second sweep to check if all instances have been covered
Comment 9•16 years ago
|
||
Well, I believe that Edward changed the behavior of this so it's no longer treated this way (but will not show up in the location bar).
Comment 10•16 years ago
|
||
I basically made TRANSITION_DOWNLOADs not hidden so they show up in the library and have notifications, but the frecency is 0, so it doesn't show up in the location bar.
Updated•16 years ago
|
Assignee: sdwilsh → nobody
Whiteboard: [needs patch]
Comment 11•16 years ago
|
||
i think we could close this and file new bugs if any issue is found when we will show downloads in the Library. For now i think there's nothing more to follow here.
Comment 12•16 years ago
|
||
(In reply to comment #11)
> i think we could close this and file new bugs if any issue is found when we
> will show downloads in the Library. For now i think there's nothing more to
> follow here.
agreed
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
Comment 13•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
You need to log in
before you can comment on or make changes to this bug.
Description
•