We can't notify viewers of asynchronously loaded batches of results as long as we're sorting in C++ after all results are retrieved. Currently we perform a first-pass sort in SQL and a final sort in C++ after all results have been loaded.

Need to decide how bug 398190 relates to this one. I'm not sure yet where exactly in the code ORDER BY clauses need to go -- at first look I was thinking PlacesSQLQueryBuilder::SelectAsURI() and friends -- but I'd be (pleasantly) surprised if multiple paths don't need to be updated.

i'd say to dupe bug 398190 to this and try to upstream all sorting, as far as possible.

This is hairier than I first thought, so I spun out bug 530236 to get started on nsNavHistoryFolderResultNode. Then I'll move on to nsNavHistoryQueryResultNode. Smaller focused bugs should be easier to review also. One problem is that nsNavHistoryContainerResultNode::FillStats must be called in some cases before the node's children are sorted. I have to find a way to do FillStats's work in SQL or avoid it altogether. One way would be to keep the stats up-to-date in the DB instead of computing them dynamically. Although, in a nightly I tried to get a folder and query container to refresh in the Library by renaming and adding children and such, but the view didn't update the containers' visit dates and visit counts like the code seems to be saying it should.