Closed
Bug 511207
Opened 16 years ago
Closed 16 years ago
last page not removed from history upon close of browser
Categories
(Firefox :: Bookmarks & History, defect)
Tracking
()
RESOLVED
FIXED
Firefox 3.7a1
| Tracking | Status | |
|---|---|---|
| status1.9.2 | --- | beta1-fixed |
People
(Reporter: mcs, Assigned: mak)
Details
(Keywords: privacy)
Attachments
(1 file)
|
4.51 KB,
patch
|
sdwilsh
:
review+
|
Details | Diff | Splinter Review |
Steps to reproduce:
1) Configure Firefox to show a blank page when it starts up.
2) Configure Firefox to clear browsing history when it closes.
3) Visit a new site and then quickly exit Firefox.
4) Start Firefox and notice that that last site is in your history even though
everything else has been cleared.
I suspect this has something to do with the lazy add strategy for history (see bug 443328).
Reproduced with Firefox 3.5.2 on Mac and Windows. Could not reproduce in 3.0.13.
| Assignee | ||
Comment 1•16 years ago
|
||
yes, it is possible that the visit is just added after clear history due to LAZY_ADD, that means you close the browser less than 3 seconds after the page starts loading.
| Reporter | ||
Comment 2•16 years ago
|
||
I am surprised that there does not appear to be a way to disable LAZY_ADD at run time (e.g., a hidden preference).
Should nsNavHistory::RemoveAllPages() clear the lazy messages list?
Should nsNavHistory::RemoveVisitsByTimeframe() clear lazy messages that fit between aBeginTime and aEndTime?
| Assignee | ||
Comment 3•16 years ago
|
||
that's an interesting question, i think so, they should clean up the lazy messages if that's applicable. There is plan to change how adding visits works, but for now we could fix it like that.
Also RemovePagesByTimeframe should do that.
Since you looked atthe code already, do you want to provide a patch?
| Assignee | ||
Comment 4•16 years ago
|
||
Probably would be easier to just force a commit before the cleanup methods start doing cleanup
#ifdef LAZY_ADD
CommitLazyMessages();
#endif
| Assignee | ||
Comment 5•16 years ago
|
||
asking blocking for privacy reasons.
Flags: blocking-firefox3.6?
Keywords: privacy
Updated•16 years ago
|
Flags: blocking-firefox3.6? → blocking-firefox3.6+
Updated•16 years ago
|
Assignee: nobody → mak77
| Assignee | ||
Comment 6•16 years ago
|
||
I can't write a test for this. Or better, i can write a test for this, but each method would require more than 3 seconds (lazy timer) to be tested, so the test would require 12 seconds to run. So, i'm flagging litmus, it's a pretty easy test to do manually.
Attachment #399885 -
Flags: review?(sdwilsh)
| Assignee | ||
Updated•16 years ago
|
Flags: in-litmus?
Comment 7•16 years ago
|
||
Comment on attachment 399885 [details] [diff] [review]
patch v1.0
r=sdwilsh
Attachment #399885 -
Flags: review?(sdwilsh) → review+
| Assignee | ||
Comment 8•16 years ago
|
||
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.7a1
| Assignee | ||
Comment 9•16 years ago
|
||
status1.9.2:
--- → beta1-fixed
| Assignee | ||
Updated•11 years ago
|
Flags: in-litmus?
You need to log in
before you can comment on or make changes to this bug.
Description
•