META REFRESH updates recorded as visits in Places' History, causing duplicates




Bookmarks & History
12 years ago
9 years ago


(Reporter: Per Ångström, Unassigned)


Firefox 3
Bug Flags:
in-testsuite +
in-litmus -

Firefox Tracking Flags

(Not tracked)





12 years ago
It seems that page updates triggered by META REFRESH are recorded as individual visits in Places' History every time they occur. This causes a lot of clutter if you happen to have such a page open for a while, especially if the page's refresh frequency is high. I suppose it unnecessarily bloats the history database as well.

I think it would be a lot better if Places only recorded page visits performed actively by the user.

How to reproduce:
1) Open the Places window and select History.
2) Open a page that uses META REFRESH, e.g. the example URL.
3) Leave the History open for some time, minimum 10 minutes.

Actual behavior: Every automatic update is recorded as an individual visit to the same page.

Desired behavior: There should only be recorded one visit to the page, namely the original visit. The automatic updates should not be recorded.
Assignee: nobody → brettw
Ever confirmed: true
Priority: -- → P2
Target Milestone: --- → Firefox 2 alpha2

Comment 2

12 years ago
This is not something that is easy to add. Meta refreshes are treated very differently from normal refreshes.

nsDocShell implements nsIRefreshURI which handles meta refreshes. This happens after the original page is added to global history. The hard part is that we have to go back in time and hide the original page. However, we don't want to hide it if it was unhidden before this most recent visit, so we'll also need to keep a list of "recently unhidden pages" so we know how to put it back. Then all of the view code needs to be updated to handle OnHide. We might need a new observer call for this.

Also, we need to decide some timeout that is reasonable where the original will be hidden. 0 seconds is the safest (only hide source if it is an immediate redirect). A few seconds might be reasonable.
Target Milestone: Firefox 2 alpha2 → Firefox 2 beta1


12 years ago
Priority: P2 → P4


12 years ago
Priority: P4 → P5
Target Milestone: Firefox 2 beta1 → Firefox 3


12 years ago
Assignee: brettw → nobody
This is actually fixed by bug 399606 (we have a test that says so!)

Note: comment 2 no longer seems to be true on trunk.
No longer blocks: 399606
Last Resolved: 11 years ago
Depends on: 399606
Flags: in-testsuite+
Flags: in-litmus-
Resolution: --- → FIXED
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.

Component: Places → Bookmarks & History
QA Contact: places → bookmarks
You need to log in before you can comment on or make changes to this bug.