We invalidate if FrameAnimator::UpdateState marks the composited frame as valid, but we fail to do so if FrameAnimator::RequestRefresh does so.
The other place that sets the composited frame as valid is RasterImage::Decode. This call is actually redundant because the UpdateState call will do the same.
Even though we will invalidate when the decode produces results we could still draw incorrectly if something else invalidates. In which case we would only draw the part of the image that was invalidated. But that should actually be impossible as explained in the comment.
We invalidate if FrameAnimator::UpdateState marks the composited frame as valid, but we fail to do so if FrameAnimator::RequestRefresh does so.
The other place that sets the composited frame as valid is RasterImage::Decode. This call is actually redundant because the UpdateState call will do the same.
Even though we will invalidate when the decode produces results we could still draw incorrectly if something else invalidates. In which case we would only draw the part of the image that was invalidated. But that should actually be impossible as explained in the comment.
We do this to avoid having one of the image loads happen before the cache entry for the image times out and the other image load after the cache entry times out.
--HG--
rename : image/test/mochitest/damon.jpg => image/test/mochitest/bug1217571.jpg
This change moves most of the logic for the threadsafety check into
nsAutoOwningThread, rather than having part of the logic live in
nsAutoOwningThread and part of the logic live in nsDebug.h. Changing
this also forces us to clean up a couple of places that replicated the
logic that lived in nsDebug.h as well.
The test image/test/browser/browser_docshell_type_editor.js used to rely on a devtools image.
Devtools are moving away from mozilla central, so here we register a new image dedicated for
this test.
MozReview-Commit-ID: Log4J0eLudV
--HG--
extra : rebase_source : 63890e9b4bbcf4de46190d42808ed92430f3c072
We only need metric from top level content document, but we dont have
any information about it in nsDOMNavigationTiming, so I add a weak
reference which points to nsDocShell.
MozReview-Commit-ID: GiJigRLYHNV
The previous patch wasn't good enough because it only prevented dispatching more setTimeouts after finish. It did nothing to stop already dispatched setTimeouts from calling ok(true,...).
We can have multiple setTimeouts from multiple frame update notifications in flight at the same time. If one of them reaches the finishing conditions the rest will too. So just guard calling finish with a global bool.
We can have multiple setTimeouts from multiple frame update notifications in flight at the same time. If one of them reaches the finishing conditions the rest will too. So just guard calling finish with a global bool.
