Closed Bug 375777 Opened 16 years ago Closed 16 years ago
27.57 KB, image/png
16.56 KB, image/png
5.86 KB, patch
|Details | Diff | Splinter Review|
20.35 KB, image/png
15.24 KB, image/png
14.68 KB, image/png
29.05 KB, image/png
Could this have been a side effect of switching to places-based global history? IIRC in Firefox 2 these URLs are added to session history but not global history, so they persist for the session but not after a restart (see e.g. bug 359115).
OS: Windows XP → All
Hardware: PC → All
in my places.sqlite file, these visits have type 0, which isn't supposed to happen. (1 - 6 are valid, see http://lxr.mozilla.org/seamonkey/source/toolkit/components/places/public/nsINavHistoryService.idl#1154) so I've added code to throw me into the debugger if we attempt to call nsNavHistory::InternalAddVisit() with 0 as the transition type. but going forward, all the places in places SQL where we do: visit_type <> 4 we should do visit_type <> 4 and visit_type <> 0
Assignee: nobody → sspitzer
Status: NEW → ASSIGNED
Target Milestone: --- → Firefox 3 M8
That sounds like the right approach.
Flags: blocking-firefox3? → blocking-firefox3+
note, for the url bar, this is not fixed. our currently URL bar query does not join against moz_historyvisits (http://lxr.mozilla.org/seamonkey/source/toolkit/components/places/src/nsNavHistoryAutoComplete.cpp#272) The fix for the url bar autocomplete part of this bug is contained in a patch for bug #389491
steps to reproduce the problem, at least with gmail: do this in a build without the fix: 1) create new profile (so our prefs are set to load homepage on startup) 2) set http://mail.google.com/mail/ as your home page 3) log into gmail, choose remember me 4) load about:blank 5) clear history 6) exit 7) restart you should get the load.html in your history sidebar (https://bugzilla.mozilla.org/attachment.cgi?id=274638) because we were not setting that non-top level load as TRANSITION_EMBED. start up a build with the fix, and you won't see those old loads (as I added visit_type <> 0) and we won't add new loads to your places.sqlite without TRANSITION_EMBED (you'll need SQLite Database Browser to verify that part.)
Comment on attachment 274637 [details] [diff] [review] patch looks ok, r=me
Attachment #274637 - Flags: review?(dietrich) → review+
morphing to reflect what this fixes. I'll log a new bug about the url bar, which will be fixed by the patch in bug #389491 for a places.sqlite to test this bug against, see bug #384677
fixed. Checking in nsNavHistory.cpp; /cvsroot/mozilla/toolkit/components/places/src/nsNavHistory.cpp,v <-- nsNavHis tory.cpp new revision: 1.150; previous revision: 1.149 done
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
I used the steps in comment 15 with the build from 6/10 (Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a6pre) Gecko/2007061004 Minefield/3.0a6pre). I can't reproduce this issue. Is there a specific regression range for this? All I get in my history menu or sidebar is the inbox page.
No longer blocks: 392392
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.