Closed Bug 330138 Opened 18 years ago Closed 17 years ago

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

Categories

(Firefox :: Bookmarks & History, defect, P5)

defect

Tracking

()

RESOLVED FIXED
Firefox 3

People

(Reporter: per.angstrom, Unassigned)

References

()

Details

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
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P2
Target Milestone: --- → Firefox 2 alpha2
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
Priority: P2 → P4
Priority: P4 → P5
Target Milestone: Firefox 2 beta1 → Firefox 3
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
Status: NEW → RESOLVED
Closed: 17 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.

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.