Add a revision tag to moz-page-thumb URLs. Change it whenever a new
thumbnail is captured and stored to disk. This prevents new loads from
re-using the old cached value even if the document context matches the
stored loadId of the cache entry.
Also drop no-longer needed wait in browser_thumbnails_update.js test.
Restores behaviour of test/head.js:retrieveImageDataForURL to that of
before bug 897880 - i.e. load the thumbnail image in the context of the
top level chrome document (rather than a new tab every time). It's
likely that bug 1192394 is the reason for the test failures observed in
bug 897880 comment #11.
Use nsISubstitutingProtocolHandler to return a SubstitutingURL and to
resolve the thumbnail URL to the backing nsIFile.
Now the image loader code will realise that moz-page-thumb:// URLs are
backed by a file and will be able to use the file mtime to evaluate
whether the cached imgRequest has expired.
* Implement the nsISubstitutingProtocolHandler methods in the thumbnail
protocol handler. The resolveURI method does all the work, the other
methods are just stubs.
* moz-page-thumb:// is now an URL rather than an URI, so update the
signature accordingly.
* Add xpcshell-test to affirm that SubstitutingURL::EnsureFile()
resolves the backing file correctly.
* Adjust the mochitest to account for the one second granularity of the
mtime tracking.
Mixed content warnings on valid https pages may sometimes occur when a thumbnail on about:newtab is refreshed while we're already transitioning to the new web page. The "insecure" request is counted as a subresource request towards the newly started load. If the new target is a https page this may result in a mixed content warning because nsSecureBrowserUI is dumb and can't tell the requests of the current and previous page loads apart.
