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
One caveat is that this change doesn't mean we handle frame visibility in
iframes in a same manner regardless whether the iframe is out-of-process or not.
In fact, we handle OOP iframe cases in a slightly different way since in OOP
iframes if the iframe is invisible because it's scrolled out or some such, then
we can't tell how far the iframe is from the visible scroll port. For example;
```
<div style="height: 100px; overflow: scroll;">
<div id="spacer" style="width: 100%; height: 200px;"></div>
<iframe style="height: 100px;"></iframe>
</div>
```
In this case, we consider all frames inside the iframe are invisible because
the iframe position is out of our frame visibility tracking margins. But if
the #spacer element's height is 100px, we consider all frames inside the iframe
viewport are visible if the iframe is in-process iframe, whereas we consider
all frames are invisible if the iframe is out-of-process iframe.
So in short, the frame visibilityn inside OOP iframes is depending on whether
the iframe gets painted in the parent document, i.e. depending on display port
and other factors controlling the paint stuff, the visibility inside in-process
iframes is depending on same factors for normal scrollable frames.
Differential Revision: https://phabricator.services.mozilla.com/D125125
Before this patch, PresShell.cpp tries to reuse a LazyLogModule that's defined
in MobileViewportManager.cpp, which isn't actually declared in any header. This
prevents the build from linking, unless we're lucky enough to have these two
source files concatenated together via our unified build.
This patch promotes this LazyLogModule to be an actual static member-var on the
MobileViewportManager class, so that it can be exported and used externally in
a more structured way. This makes it consistent with the very-similar
"PresShell::gLog" member-variable.
Differential Revision: https://phabricator.services.mozilla.com/D125600
Disabled by default, browser.places.interactions.enabled, this adds scrolling metrics (time spent scrolling and distance scrolled) to the history metadata.
Differential Revision: https://phabricator.services.mozilla.com/D120656
Decisions about visual or layout viewport type coordinates are made based on cross process root content docoument (not in process).
Differential Revision: https://phabricator.services.mozilla.com/D124271
Remove the need to post a runnable to coalesce them (we still coalesce
theme changes because those do non-trivial work).
What can go on is that on cold load we load the font list async, and
that goes through this code via a faked font.internaluseonly.changed
pref change, which stores a reframe change hint in
mChangeHintForPrefChange.
If the page flushes after this code runs, but before the next refresh
driver tick, we will be just wasting work. So instead do the
RebuildAllStyleData call synchronously. It just schedules a flush and
posts a hint, so it doesn't do the work right there, but makes the next
flush do the work as needed, so it should be faster and also more
correct.
Also improve handling of preference sheet prefs and such to avoid more
wasted work when we go through this code, as the assumption their
handling was doing was that it gets called infrequently, but it's not
the case due to the font list updates.
Differential Revision: https://phabricator.services.mozilla.com/D123103
