While working to reproduce the stale content bug with tab warming
I realized that my work here had inadvertently clobbered tab
warming by immediately calling the tab unload code. This wasn't
necessary, and I didn't need to put the cached tab deactivation
code in the unload method, it just seemed initially convenient.
This should make more sense overall.
MozReview-Commit-ID: 9v9dYZTa1Dv
This is fairly straightforward, other than the fact that the
nomenclature gets a bit awkward with the aForce parameter on
the ForcePaint methods. I'm not sure which direction to go with
this - "aForce" seems a fairly intuitive name for what we want,
and I'm kind of inclined to say the existing ForcePaint mechanic
should be renamed to something like PaintWithInterrupt, or
PaintWithPriority.
MozReview-Commit-ID: Bj9DROug1pC
We maintain a simple LRU cache of tab layers by setting their
docShellIsActive = false with preserveLayers(true). Once they
are pushed out of the cache by more recently used tabs, their
layers are discarded.
Luckily most of the complexity of this could be contained in
the AsyncTabSwitcher - the one change that had to sit outside of
that was moving the aTab.closing = true earlier in the removeTab
call, so that we could use that information to eagerly evict tabs
from the cache. This was to address a leak in a few tests on try.
MozReview-Commit-ID: 2E3uU8LEYkD
We maintain a simple LRU cache of tab layers by setting their
docShellIsActive = false with preserveLayers(true). Once they
are pushed out of the cache by more recently used tabs, their
layers are discarded.
Luckily most of the complexity of this could be contained in
the AsyncTabSwitcher - the one change that had to sit outside of
that was moving the aTab.closing = true earlier in the removeTab
call, so that we could use that information to eagerly evict tabs
from the cache. This was to address a leak in a few tests on try.
MozReview-Commit-ID: 2E3uU8LEYkD
We maintain a simple LRU cache of tab layers by setting their
docShellIsActive = false with preserveLayers(true). Once they
are pushed out of the cache by more recently used tabs, their
layers are discarded.
Luckily most of the complexity of this could be contained in
the AsyncTabSwitcher - the one change that had to sit outside of
that was moving the aTab.closing = true earlier in the removeTab
call, so that we could use that information to eagerly evict tabs
from the cache. This was to address a leak in a few tests on try.
MozReview-Commit-ID: 2E3uU8LEYkD
We maintain a simple LRU cache of tab layers by setting their
docShellIsActive = false with preserveLayers(true). Once they
are pushed out of the cache by more recently used tabs, their
layers are discarded.
Luckily most of the complexity of this could be contained in
the AsyncTabSwitcher - the one change that had to sit outside of
that was moving the aTab.closing = true earlier in the removeTab
call, so that we could use that information to eagerly evict tabs
from the cache. This was to address a leak in a few tests on try.
MozReview-Commit-ID: 2E3uU8LEYkD
It looks like TabChild::RenderLayers already does the work of suppressing the displayport,
so all of the suppression and bookkeeping that AsyncTabSwitcher is doing is superfluous
and probably opening us up to weird graphical glitches (like the one associated with this
bug).
MozReview-Commit-ID: 5qIVguSMsnr
It looks like TabChild::RenderLayers already does the work of suppressing the displayport,
so all of the suppression and bookkeeping that AsyncTabSwitcher is doing is superfluous
and probably opening us up to weird graphical glitches (like the one associated with this
bug).
MozReview-Commit-ID: 5qIVguSMsnr
We suppress the displayport when requesting a tab or warming it, in order to reduce
the amount of work that the content process needs to do to paint it (we paint just
the displayport area and nothing around it). Afterwards, we unsuppress the displayport
so that we can paint the surrounding areas when scrolling. We normally do this
unsuppression in destroy(), but with tab warming, that unsuppression can happen
after a few seconds (after the tab warming eviction timeout).
This results in users seeing checkerboarding sometimes, where the tab they're looking
at is still suppressing its displayport and waiting for the timeout to complete.
This patch updates the AsyncTabSwitcher to unsuppress the displayport for a tab as
soon as the tab has been switched to, instead of waiting for the timeout.
Out of an abundance of caution, we still unsuppress displayports for tabs that
never get to enter the STATE_LOADED state, although that really should never
happen.
MozReview-Commit-ID: 5qIVguSMsnr
Since bug 1432509, the warmingTabs WeakSet has had warmed tabs
cleared from it once they have entered STATE_LOADED. This allowed
us to make decisions on tab switch operations based on whether or
not a tab was still being warmed.
This broke our Telemetry, which assumed that warming tabs would
still be in the warmingTabs WeakSet until either requested or
evicted. Now, instead, we look to see whether or not tab warming
is enabled, and whether tabs _could_ have been warmed in order to
add entries to the right buckets.
MozReview-Commit-ID: 94oiKYzf4au
