415716 - Odd Behavior when querying MaxVisits while changing visit types

Status: RESOLVED DUPLICATE of bug 416313

(Firefox :: Bookmarks & History, defect)

Description

[cmtalbert]

Attachment: The test for this bug.

While trying to write a query test, I noticed an odd behavior concerning the transition type of the visit and the way that it pertains to maxVisits on the query.

The XPCShell test is attached, but I'll describe it briefly here:
I have a set test that limits results based on Annotation, relative time, minvisits and maxvisits.  The URL I am adding has too many visits (> maxVisits) and therefore should not show up in the query results.

My query.maxVisits is set to 10.

If I set the number of visits in line 106 to "13" then the test works as expected.  If I set the number of visits in line 106 to "12" then all twelve of the URI's visits end up in the results object.  

Also, if I set the "transition type" to default to any of the possible values (rather than varying as I have it) then the problem does not occur.  For example, if I set it to TRANSITION_TYPED then the problem does not occur.  I can hard code this to any value, and the problem does not occur.

So, something to do with mixing TRANSITION_* values causes the query engine to disregard the maxVisit restriction.

Comment 1

[Marco Bonardo [:mak]]

query.maxVisits limits on moz_places.visit_count that does not take in count some kind of visit (transition EMBED)
so with 12 and your for cycle you have 10 valid visits, and 2 visits EMBED, 12 total visits but visit_count is still 10 since 2 did not increment the count

Comment 2

[cmtalbert]

Marco, thanks for the infromation.  I've confirmed that this is in fact the case.  If you take out the EMBED transition type, then the test passes.

Shouldn't we update the comment in the IDL [1] to reflect this so that others don't make a similar mistake?

[1]: http://mxr.mozilla.org/mozilla/source/toolkit/components/places/public/nsINavHistoryService.idl#1111

If you think the comment should be updated, I'll change this bug to reflect that, if not, I'll mark it INVALID.

Comment 3

[Marco Bonardo [:mak]]

see Bug 416313

Comment 4

[cmtalbert]

Bug 416313 looks like it will land and will resolve this issue.  I'm going to dupe this bug against that one.

Comment 5

[Gervase Markham [:gerv]]

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