treat TRANSITION_DOWNLOAD like we treat TRANSITION_EMBED visits

RESOLVED WORKSFORME

Status

()

Firefox
Bookmarks & History
P4
normal
RESOLVED WORKSFORME
11 years ago
8 years ago

People

(Reporter: Seth Spitzer, Unassigned)

Tracking

Trunk
Points:
---
Bug Flags:
blocking-firefox3 -
wanted-firefox3 +

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

11 years ago
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

11 years ago
perhaps dietrich can work this into bug #394038
Flags: blocking-firefox3?
Flags: blocking-firefox3? → blocking-firefox3+

Updated

10 years ago
Assignee: nobody → sdwilsh
Whiteboard: [needs patch]
dietrich, is this done?
Priority: -- → P3
(In reply to comment #2)
> dietrich, is this done?
I don't think so.  I'll find out by tonight?
not done

related: bug 412219.

Updated

10 years ago
Priority: P3 → P4
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

10 years ago
partly implemented for visit_count
Is this bug still valid?

Comment 8

10 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

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

10 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

10 years ago
Assignee: sdwilsh → nobody
Whiteboard: [needs patch]
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.
(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
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME
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.