when resetting the history sidebar view by the "View" button, don't use applyFilter(). When you use applyFilter with no search terms, the query uri for the nsNavHistoryQueryResultNode is different. specifically, it doesn't contain "beginTime=-2592000000000&beginTimeRef=1&endTime=7200000000&endTimeRef=2", which is part of our history query. this wasn't a problem, except for bug #380735 we build up a urn using the node's uri. so these are not the same rdf resource: urn:places-persist:beginTime=-2592000000000&beginTimeRef=1&endTime=7200000000&endTimeRef=2&group=0&sort=1&type=1,-1,mail.mozilla.com urn:places-persist:place:group=0&sort=1&type=1,-1,mail.mozilla.com This is needed by bug #380735. hmm, maybe we can fix this (and improve history performance) by *not* specifying the beginTime and endTime at all, for either the history side bar or the history menu, because we really want all visits, and we're paying an overhead by checking the time! I still think we should avoid calling applyFilter() with no search string, but I'll test the other side of this fix as well, which is to drop the time part of our history queries.
11 years ago
Created attachment 268583 [details] [diff] [review] patch this patch both fixes the issue of not calling applyFilter() without a search value (instead, calling initPlace(), which is just the same code that we call when the history sidebar loads) but also, we stop doing time searches (for both history sidebar and history menu) which should be a performance win. once I finish testing, I'll seek a review.
Created attachment 268597 [details] [diff] [review] patch just fix history-panel.js here, needed bug #380735, and will spin off the other fix as a performance bug.
> will spin off the other fix as a performance bug. see bug #384677
Status: NEW → ASSIGNED
Comment on attachment 268597 [details] [diff] [review] patch correct patch coming
Created attachment 268605 [details] [diff] [review] patch previous patch would not call applyFilter() after the initial call to searchHistory(), so if you typed "goo" we'd search, but add "gle" to get "google" we would not call applyFilter(). doh.
Created attachment 268884 [details] [diff] [review] updated, per mano, call load() directly
Comment on attachment 268884 [details] [diff] [review] updated, per mano, call load() directly r=mano.
Attachment #268884 - Flags: review?(mano) → review+
Created attachment 268888 [details] [diff] [review] move and clean up the comment
Attachment #268888 - Flags: review?(mano) → review+
fixed. cvs ci browser/components/places/content/history-panel.js Checking in browser/components/places/content/history-panel.js; /cvsroot/mozilla/browser/components/places/content/history-panel.js,v <-- hist ory-panel.js new revision: 1.18; previous revision: 1.17 done
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Does this really need to block, Seth? Is there a major chance of it regressing due to other work?
> Does this really need to block, Seth? No, so clearing the request. > Is there a major chance of it regressing due to other work? No, I don't think this would regress due to other changes.
Can someone verify this change or tell us how to do so in order to mark this as verified and get it off everyone's plate?
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.