Bug 416313 added the original setting of frecency to -visit_count, and this included among other changes.. reordering some queries so that we can grab visit_count before we wipe the visits. Bug 476298 made it so that we just recalculate all invalid frecencies in one go, so there's no need to order by the negative frecencies.

Oh, I forgot to emphasize the main reason :p Because we do frecency = -MAX(visit_count, 1), some queries are more complex than necessary especially while expiring. Such as getting the visit count of pages that we *won't* expire, then expire the pages. Whereas we could just expire pages and set the remaining pages' frecency to -1.

This is a sensible improvement to do, taking since I just hit this code in another bug and remembered there was a bug filed about this.

First use of UPDATE WHEN CASE END, I originally thought it was only for SELECTs, I'll find more uses for it. Btw, before we were setting frecency to -visit_count for all entries that we evaluated to stick after cleanup, removing pages, then fixing frecencies for unvisited livemarks and place: queries. With the patch we just asynchronously set frecency to -1 or 0 on the remaining entries after the cleanup, this has some advantages: query is simpler, 1 query rather than 2, async IO. This bug depends on bug 674210 from a code-merge point of view.