aForceRepaint wasn't doing what it claimed to do at all, as we've recently
learned. In current mozilla-central:
* All those arguments ended up in a RecvRenderLayers with aForceRepaint = true
(so far so good, that's expected).
* But it was ignored (so that aForceRepaint is always true to calls to
MakeVisible) from UpdateVisibility:
https://searchfox.org/mozilla-central/rev/f43ae7e1c43a4a940b658381157a6ea6c5a185c1/dom/ipc/BrowserChild.cpp#2523
* Plus that argument only does anything useful on current central if we get to
the end of MakeVisible(true). And MakeVisible() early returns if already
visible.
So all in all this seems somewhat useless, and nobody has complained about such
a thing in a long time.
It seemed to do what it promised when it was introduced in
https://hg.mozilla.org/mozilla-central/rev/27f6f789b194, but it seems the
refactoring in https://hg.mozilla.org/mozilla-central/rev/4df5fa6fa785 broke it.
I think the new setup is somewhat easier to reason about, and nobody seems to be
missing that.
I'll try to remove the forceRepaint() call itself on a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D47127
--HG--
extra : moz-landing-system : lando
That is, for fission iframes. For top level stuff we rely on the tab switcher
going through SetDocShellIsActive and such.
See the expanded comment as for why. Ideally we could simplify this further by
not making RecvRenderLayers update the visibility (which spins the refresh
driver and such).
It's a bit suspect because it's very easy to get to an inconsistent state if the
browser chrome does something wrong.
I'll try to do that, but for now this should improve the fission situation
anyway.
Differential Revision: https://phabricator.services.mozilla.com/D46706
--HG--
extra : moz-landing-system : lando
The MultiLookupHuffmanTable is designed to allow fast lookup in tables that
have a max bit length too large for the SingleLookupHuffmanTable.
We will probably need to tune the bit lengths at which we switch from SingleLookup to TwoLookups or ThreeLookups in followup patches.
Differential Revision: https://phabricator.services.mozilla.com/D46806
--HG--
extra : moz-landing-system : lando
Since we've upgraded to clang 9, clang-format changed and now uses dynamic libraries
for the clang tooling lib that it leverages.
Differential Revision: https://phabricator.services.mozilla.com/D47265
--HG--
extra : moz-landing-system : lando
In the existing test, we also check expanding a node, as well as navigating
with the keyboard.
Differential Revision: https://phabricator.services.mozilla.com/D47272
--HG--
extra : moz-landing-system : lando
The actors weren't ever removed from the state,
which could lead to increased memory consumption
as well as attempt to release the actors a
second time in some cases.
We fix this by dispatching a new actions once
the actors are released, so we can remove them
from the state.
Depends on D47271
Differential Revision: https://phabricator.services.mozilla.com/D47411
--HG--
extra : moz-landing-system : lando
When using the ObjectInspector in an inspector extension sidebar,
document is not an HTMLDocument but a Sandbox, which means we
don't have access to the same properties than in a document.
Since the Tree and the ObjectInspector components do use `document`
and `window`, this means some interaction would lead to the sidebar
crashing.
To prevent this, we retrieve the document and/or the window from
a node reference instead.
Differential Revision: https://phabricator.services.mozilla.com/D47271
--HG--
extra : moz-landing-system : lando
I wanted to fix the more general problem and script-block more of
FlushPendingNotifications, but simple attempts to do that have resulted in
terribly orange try runs with very bizarre failures, so in the "perfect is the
enemy of good" spirit, fix the issue at hand (scroll anchoring adjustments not
dealing with layout reentering beneath them) by running them while
script-blocked, which is the right thing to do anyway.
Differential Revision: https://phabricator.services.mozilla.com/D47256
--HG--
extra : moz-landing-system : lando
The MultiLookupHuffmanTable is designed to allow fast lookup in tables that
have a max bit length too large for the SingleLookupHuffmanTable.
We will probably need to tune the bit lengths at which we switch from SingleLookup to TwoLookups or ThreeLookups in followup patches.
Differential Revision: https://phabricator.services.mozilla.com/D46806
--HG--
extra : moz-landing-system : lando
I added this constructor to sort with other types.
However, it was mistake. We don't use it.
Differential Revision: https://phabricator.services.mozilla.com/D47407
--HG--
extra : moz-landing-system : lando
Depends on D47051.
Without the trait, we keep calling the connect() wrapper on the actor, which is supposed to be deprecated
Differential Revision: https://phabricator.services.mozilla.com/D47053
--HG--
extra : moz-landing-system : lando
Depends on D47050. Trait was added in 2017, all servers should now have support this by default
Differential Revision: https://phabricator.services.mozilla.com/D47051
--HG--
extra : moz-landing-system : lando
