We only have to iterate over the open popups list (which is usually 0 or single digits) instead of every view.
Now that comboboxes definitely cannot create views, only xul menu popups can be floating popups.
Differential Revision: https://phabricator.services.mozilla.com/D138290
nsPresContest::RegisterManagedPostRefreshObserver still lets us add a managed post refresh observer until the mPresShell pointer on the prescontent is nulled out. That means that between the call to CancelManagedPostRefreshObservers and mPresContext->DetachPresShell() (which nulls out the mPresShell pointer on the prescontext) in PresShell::Destroy we can add a managed post refresh observer that will never get removed. Notably, destroying the frame tree happens between these two calls.
So move the CancelManagedPostRefreshObservers call to happen right after we null out the mPresShell pointer on the prescontext.
In bug 1737503 I want to add a managed post refresh observer when we destroy a subdocument frame (it's only interested in the recreate frames case not the destruction case, but not an easy way to tell them apart afaik), so it triggers this bug. The patch and test I have for that bug exercise this scenario.
Differential Revision: https://phabricator.services.mozilla.com/D135340
Extensions are using getComputedStyle(body).backgroundColor, which is
wrong at multiple levels.
The one that matters for this bug is that it is not color-scheme aware.
Depends on D133770
Differential Revision: https://phabricator.services.mozilla.com/D133771
No behavior change (you can't have an in-process frame container and a
BrowserChild at the same time), but avoids some needless refcounting
overhead and makes it simpler to follow.
Differential Revision: https://phabricator.services.mozilla.com/D133770
I guess we need to do this every time we get a new APZC tree manager (because that is where the zoom constraints map/cache is stored). I'm not sure how to detect that or if there are other cases we haven't covered.
Differential Revision: https://phabricator.services.mozilla.com/D113608
It's an internal API corresponding to `Selection.getRangeAt` DOM API.
I think that it should use `uint32_t` rather than `size_t` because of the
consistency with the DOM API and `Selection::RangeCount()`.
This patch fixes all callers of `GetRangeAt()`, and rewrites it with ranged-
loops unless original ones do not refer `RangeCount()` every time and may run
script in the loop.
Differential Revision: https://phabricator.services.mozilla.com/D128848
Building with --disable-xul has been busted since _at least_ bug
1082579, for more than 7 years (I didn't try to track that down
further). It's time to recognize that the option serves no purpose.
Differential Revision: https://phabricator.services.mozilla.com/D133161
We only need to clean up the frames for its flat tree children which are
about to go away from the flat tree, but we don't need to do anything
else. This avoids issues with the following patches because menupopups
depend a lot on their frame tree state.
Differential Revision: https://phabricator.services.mozilla.com/D131083
Otherwise if we get an event targeting a different suppressed pres shell
while we're unsuppressing we might get stuck delaying the event over and
over, see the links in comment 33.
Not sure how to get a repro for this, the patch is written based on the
pernosco session, but suggestions welcome.
Differential Revision: https://phabricator.services.mozilla.com/D130100
Remove the follow-firefox-theme pref as now that's default everywhere,
and document better the behavior of the color-scheme property by
reworking and commenting the logic on it a bit.
Differential Revision: https://phabricator.services.mozilla.com/D128610
We have JS listeners that are expected to run once the LookAndFeel
caches have been cleared and such, so split the look-and-feel-changed
notification into an internal and external notification.
Differential Revision: https://phabricator.services.mozilla.com/D128097
This patch shouldn't change behavior at all.
This patch replaces a manual NS_ADDREF call with typesafe code that manages the
reference count for us. This reduces repeated boilerplate code, in the
implementation as well as the callsites.
Differential Revision: https://phabricator.services.mozilla.com/D127179
This patch shouldn't change behavior at all.
This patch replaces a manual NS_ADDREF call with typesafe code that manages the
reference count for us. This reduces repeated boilerplate code, in the
implementation as well as the callsites.
Differential Revision: https://phabricator.services.mozilla.com/D127179
The issue here is that we don't clear the cached intrinsic size of the
flex item, but this reproduces without flex at all.
The main issue is that we choose whether to clear the intrinsic sizes
from a reflow root (the outer svg in this case) based on whether the
reflow changes size or position:
https://searchfox.org/mozilla-central/rev/3fa5cc437a4937c621ea068ba5dc246f75831633/layout/base/RestyleManager.cpp#1224-1229
This is ~fine, except the nsChangeHint_ReflowChangesSizeOfPosition hint
can be "inherited" (and thus be cleared if already subsumed by a
parent):
https://searchfox.org/mozilla-central/rev/3fa5cc437a4937c621ea068ba5dc246f75831633/layout/base/nsChangeHint.h#465-469
This is ~fine, as we'll already start the reflow further up the tree (so
we don't need to start go past the reflow root), but we still need to
clear the ancestor intrinsics. We still get to StyleChangeReflow with
the ClearAncestorIntrinsics hint. We could pass that information down,
but the information is really already in via the IntrinsicChange.
I think it's just not correct to stop clearing intrinsic sizes if the
target is a reflow root and we get a TreeChange/StyleChange, regardless
of whether it changes size/position. It should also be a few less
instructions, though not that it matters.
Depends on D126812
Differential Revision: https://phabricator.services.mozilla.com/D126813
Unsuppressing is done only if the page can use stylesheet cache. That should mean the
load isn't a cold load and also some other resources may be cached and thus
painting could happen sooner.
There is currently a regression around dom.ipc.processCount.webIsolated handling, but the
testing has been done with dom.ipc.processCount.webIsolated==1, and the patch for bug 1731792
should give back similar behavior as what process count 1 has.
Differential Revision: https://phabricator.services.mozilla.com/D125878
