Promoted from http://tenfourfox.tenderapp.com/discussions/problems/213-cant-search-bookmarks

See issue ticket. Regression from 14.

Regression window: 11.0b2 and 12.0 work. 13, 14, 15 and 15.0.1 don't.

I'll diff the changelogs between 12 and 13 later today. Thanks for the testing. I wonder why the OP said it worked for him in 14, though.

(ftr, just tried it on my 7400 test system; 12 works, 13 doesn't, just like you said)

I wonder why the OP said it worked for him in 14, though.

I am the OP, what I actually said, somewhat ambiguously, was that it hadn't worked "since version 14", meaning that version 14 was the first version I'd tried that didn't work. (I somehow missed the release of 13 and so hadn't tried it.)

Sorry for the ambiguity

Testing this in aurora 17, searching history from the same window does work, but not searching bookmarks.

Bookmark searching from the Awesome bar does work, except that it pulls in all the history stuff as well. Even if I delete the bookmarked page from history, the awesome bar will still retrieve it if it is in bookmarks. So that's a workaround at least, and does imply that the data store is not corrupt.

applyFilters() and load() in browser/components/places/content/tree.xml allege that the offending function is "PlacesUtils.history.executeQueries" (and this appears to be toolkit/component/places/nsNavHistory.cpp:nsNavHistory::ExecuteQueries). nsNavHistoryResult.cpp appears to be where the actual (non)population of the result occurs.

Talked to Marco at Mozilla. In this SQL, logged through NSPR, this is wrong:

SELECT b.fk, h.url, COALESCE(b.title, h.title) AS page_title, h.rev_host, h.visi t_count, h.last_visit_date, f.url, null, b.id, b.dateAdded, b.lastModified, b.pa rent, (SELECT GROUP_CONCAT(t_t.title, ',') FROM moz_bookmarks b_t JOIN moz_bookm arks t_t ON t_t.id = +b_t.parent WHERE b_t.fk = b.fk AND t_t.parent = 4 ) AS ta gs , h.frecency FROM moz_bookmarks b JOIN moz_places h ON b.fk = h.id LEFT OUTER JOIN moz_favicons f ON h.favicon_id = f.id WHERE NOT EXISTS (SELECT id FROM moz _bookmarks WHERE id = b.parent AND parent = 4) AND (( AUTOCOMPLETE_MATCH( 'inequality' , h.url, page_title, tags, 0, 0, 0, 0, 4, 0) AND b.parent IN( 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 ) AND NOT h.url BETWEEN 'place:' AND 'place;' )) ORDER BY b.id ASC

Notice the parent IDs are all zero. The offending code is in nsNavHistory.cpp:

clause.Condition("b.parent IN(");
for (nsTArray<int64_t>::size_type i = 0; i < includeFolders.Length(); ++i) {
  clause.Str(nsPrintfCString("%d", includeFolders[i]).get());
  if (i < includeFolders.Length() - 1) {
    clause.Str(",");
  }
}

The offending bug is M702639 which converted 32-bit parent IDs to 64-bit. This also affects AuroraFox, so adding Tobias.

We should use "%" PRIi64 "..." for this instead of %d, since we're already requiring inttypes.h for the int64_t. Marco asked for this to be upstreamed, so I'll do that after I make sure this works.

Actually, after fooling around with this in NSPR, a better solution that works is just to turn %d into %lld.

https://bugzilla.mozilla.org/show_bug.cgi?id=793523