The "select" event handler workaround was originally added in bug 1379270 to make it
possible to focus and select the URL bar a little bit later. This ugly hack was to
workaround an issue with WebExtensions that override about:newtab with the
chrome_url_overrides property (the issue would be that the URL bar would not be
properly focused and selected if about:newtab was overridden).
Back in the day, this was necessary because the overriding URL was fully displayed
in the URL bar (moz-webextension://...). These days, when about:newtab is overridden,
the URL bar is still empty - we just end up showing the information about the
WebExtension overriding about:newtab to the left of the URL bar.
So I think we can remove the old workaround.
Differential Revision: https://phabricator.services.mozilla.com/D3447
--HG--
extra : moz-landing-system : lando
This allows the JS to work in HTML documents, where whitespace is preserved. In XUL
documents, whitespace is ignored when parsing so text nodes are generally not returned.
The following changes were made, with manual cleanups as necessary (i.e. when firstChild actually
refers to a text node, or when firstChild is used in a loop to empty out an element):
firstChild->firstElementChild
lastChild->lastElementChild
nextSibling->nextElementSibling
previousSibling->previousElementSibling
childNodes->children
MozReview-Commit-ID: 95NQ8syBhYw
--HG--
extra : rebase_source : 186d805f7a2a56694dda9032aceac2dfe5424753
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
--HG--
extra : rebase_source : fe1d6f4f87df11d5ed495e309a4a0f144bfc2143
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
--HG--
extra : rebase_source : a3d91fec940d83325d36bafb13fe892e9c9530e8
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
--HG--
extra : rebase_source : d2865fd1ee10db17d9f41cca059a5cee697f259d
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
--HG--
extra : rebase_source : b7e7bb3fcf1ed59e79a7c9fb9d3e6ce735ab54e9
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
--HG--
extra : rebase_source : b7e7bb3fcf1ed59e79a7c9fb9d3e6ce735ab54e9
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
--HG--
extra : rebase_source : 1de7c196b14b2f3a368bfbae970808cbf49e6e36
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
--HG--
extra : rebase_source : 59e72715791cb8aa25310e48b5a02e1b86762543
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
--HG--
extra : rebase_source : 35f944a324415401c4a28ed0006baf9361ef73c8
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
--HG--
extra : rebase_source : 90c0d617ac3d43a8d4513e864ba2f0a3228a5582
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
--HG--
extra : rebase_source : 0b6be98ff93d9753fcdacbec15a2a7b08232bb3a
Mike Conley
Matt Woodrow
Brian Grinstead
Doug Thayer
Bogdan Tara
Dorel Luca
Dão Gottwald
arthur.iakab
Gurzau Raul
Csoregi Natalia
Kiran
Daniel Almeida
Vivek Dhingra