when resetting the history sidebar view, don't use applyFilter()

RESOLVED FIXED in Firefox 3 alpha6

Status

()

Firefox
Bookmarks & History
RESOLVED FIXED
11 years ago
9 years ago

People

(Reporter: (not reading, please use seth@sspitzer.org instead), Assigned: (not reading, please use seth@sspitzer.org instead))

Tracking

Trunk
Firefox 3 alpha6
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 4 obsolete attachments)

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.
Flags: blocking-firefox3?
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.
Attachment #268583 - Attachment is obsolete: true
Attachment #268597 - Flags: review?(dietrich)
> 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
Attachment #268597 - Attachment is obsolete: true
Attachment #268597 - Flags: review?(dietrich)
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.
Attachment #268605 - Flags: review?(dietrich)
Created attachment 268884 [details] [diff] [review]
updated, per mano, call load() directly
Attachment #268605 - Attachment is obsolete: true
Attachment #268884 - Flags: review?(mano)
Attachment #268605 - Flags: review?(dietrich)
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 #268884 - Attachment is obsolete: true
Attachment #268888 - Flags: review?(mano)
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.
Flags: blocking-firefox3?
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.