Since WebRenderLayerScrollData nodes are emitted on the way out
of the recursion over the display list, we need to be careful
that a deferred transform doesn't end up on a deeper node than
it should be.
Differential Revision: https://phabricator.services.mozilla.com/D123397
Automatically generated path that adds flag `REQUIRES_UNIFIED_BUILD = True` to `moz.build`
when the module governed by the build config file is not buildable outside on the unified environment.
This needs to be done in order to have a hybrid build system that adds the possibility of combing
unified build components with ones that are built outside of the unified eco system.
Differential Revision: https://phabricator.services.mozilla.com/D122345
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
To look up/instantiate platform fonts based on CSS font properties, we create a gfxFontGroup from an nsFont and other attributes; this is currently cached in an nsFontCache attached to the nsDeviceContext.
However, this assumes that the mapping to platform fonts will be the same for all documents using the given device context. In a world where visibility of platform fonts to the page may be restricted, and may depend on the individual document (e.g. if the user disables tracking protection for a particular site), the mapping represented by nsFontCache may vary, and determining how to resolve a given font request will need access to the requesting document in order to know what visibility it is allowed.
To support this, this patch moves the nsFontCache from nsDeviceContext to nsPresContext. In itself, this should cause no visible change in behavior, but it provides a basis for the patches that will follow in bug 1715501.
It's likely that this will have some effects on individual performance tests, depending on the exact content and sequencing of page loads, because of changed caching behavior. E.g. having a per-presContext cache may sometimes mean that we no longer take advantage of a cached gfxFontGroup that a previously-loaded page created; but on the other hand the caches will tend to be smaller and have faster lookups.
My testing so far suggests that we will see some apparent regressions, alongside some improvements, but that overall there should be little change. I'd like to get this change landed separately, before any of the actual font-visibility behavior changes, so that we can more clearly see and isolate any unexpected effects.
Differential Revision: https://phabricator.services.mozilla.com/D122715
Though the test funtion is called twice since the parent document reloads the
iframe document, but the test will not run for the second call since it's
prevented by `testRunning` flag in test_bug851485.html.
Differential Revision: https://phabricator.services.mozilla.com/D122662
Scaling currently doesn't work in print preview tests. This adds a test that
will begin to fail if scaling gets fixed, to tell us to enable the actual
scaled content test instead.
See bug 1725486 for the scaling issue.
Differential Revision: https://phabricator.services.mozilla.com/D122292
This test was disabled for some sort of failure on Windows ASAN configurations,
several years ago.
The bug doesn't have details on the failure, but it's likely the failure was a
version of the same race condition that turned up (and was recently fixed) in
bug 1720485. So, let's see if we can reenable this test on Windows ASAN now.
Differential Revision: https://phabricator.services.mozilla.com/D122314
Font inflation isn't required for pages whose viewport is narrow enough that we
don't have to zoom *out* when doing zoom-to-fit.
As the viewport scale is given as a CSSToScreenScale, this means that what we're
actually doing at the moment, though, is comparing the width of the viewport in
CSS pixels to the width of the screen in physical pixels, *without* taking the
default scale on a high-DPI device into account.
This issue affects neither pages using a "width=device-width" viewport (the
IsAutoSizeEnabled() check handles those), nor pages without an explicitly
specified viewport at all (the viewport info returns the minimum zoom level in
that case, i.e. 25 %, which would therefore require a device scale of > 4 in
order for us to erroneously turn off font inflation - even modern phones don't
seem to quite reach *that* sort of pixel density, e.g. a Pixel 5 only reports a
default scale of ~2.73.
For pages with an explicitly sized viewport this can however mean that we turn
off font inflation too early: Slashdot e.g. uses "width=1000", which means that
on a phone with a 720 px screen font inflation is correctly enabled, but on a
different phone squeezing 1080 px into the same physical screen width (i.e.
higher DPI, but *not* a physically larger screen), font inflation is suddenly
and incorrectly turned off.
Differential Revision: https://phabricator.services.mozilla.com/D122059
For pages with an explicitly sized viewport, whether or not we enable font
inflation depends on whether the viewport is larger than content viewer size (so
it will be displayed zoomed out) or not.
For historical reasons, so far we've used the screen size as a proxy for the
content viewer size. On a phone this is a reasonable approximation (albeit a bit
less so now that Android also offers split-screen and picture-in-picture modes),
but when testing/debugging on a desktop computer, this means that the results
will depend on the screen size of the machine in question, which makes it rather
hard writing sensible test cases for that scenario.
Therefore, we're finally following up with that TODO comment in the existing
code and start using the content viewer size of the top-level document instead.
Fission means that approach won't easily work for cross-process iframes, but
given that the current calculations don't make much sense for frames anyway, we
just accept that limitation, since a proper solution as per bug 1724311 would
obsolete any work done here anyway.
Differential Revision: https://phabricator.services.mozilla.com/D122057
And make sure the caret ends up being visible, rather than _not_
visible.
This should be implementable on windows as well. It seems macOS doesn't
have a timeout thing.
Differential Revision: https://phabricator.services.mozilla.com/D122132
nsPresContext has a flag that caches the value of this pref, and the flag gets
updated in the next refresh driver tick after a pref-change occurs. Right now
we don't have a strong guarantee that the flag will have been updated by the
time the test assumes that it has, which is why we're seeing intermittent
failures.
This patch adjusts the test so that it waits for a double-rAF before proceeding
from its pref adjustment. I believe this is the recommended way of forcing &
waiting-out at least one refresh driver tick; and this should let the test
reliably assume the pref-adjustment has taken effect.
Differential Revision: https://phabricator.services.mozilla.com/D122169
It's possible to observe an element in the iframe while the
ResizeObserver object lives in the outer document, so we have to make
sure we also schedule the observer for all documents in the same
BrowsingContext tree.
Differential Revision: https://phabricator.services.mozilla.com/D119843
In the case of reflowing caused by full zoom changes, the mDisplaySize isn't
changed, whereas mMobileViewportSize should be changed.
Differential Revision: https://phabricator.services.mozilla.com/D120190
It's unused on mozilla-central, and Thunderbird can just use the canvas
frame as regular (X)HTML documents, so just use a canvas frame instead
of an nsRootBoxFrame for XUL as well.
nsRootBoxFrame was needed because of various XUL-specific things like
tooltips and so on lived there. But with the move away from XUL, that
functionality has been added to nsCanvasFrame already, behind a
principal check instead.
This also allows simplifying our background propagation setup, which was
only half-working for XUL documents (this bug is a consequence of that).
With this, most of the callers of nsCSSRendering::IsCanvasFrame can go.
They're only two of the frames that would return true for that that
actually paint backgrounds (nsCanvasFrame and nsRootBoxFrame), so the
codepaths in display list building and painting can just check
frame->IsCanvasFrame() instead.
The remaining caller to that function is
nsContainerFrame::SyncWindowProperties, and the change is also legit, in
the sense that the only thing SyncWindowProperties() really cares about
is propagating the max/min-width constraints from the root element's
style to the view/widget, and the only frame that would return true from
IsCanvasFrame and have a view is the viewport frame which is the root of
the frame tree.
Differential Revision: https://phabricator.services.mozilla.com/D90846
This should pretty much match our non-fission behavior. I found the
original approach of keeping the frameloader from nsSubDocumentFrame
quite hard to get green on try unfortunately, because among other
things, the new frameloader wouldn't get the right viewport sizes /
position / etc.
Differential Revision: https://phabricator.services.mozilla.com/D121198
Part of the issue with the profile in the blocked bug is that 30% of the
time is spent in nsLayoutUtils::FindNearestCommonAncestorFrame from
DOMIntersectionObserver::Update. That shouldn't be needed since in most
cases we know we're an ancestor.
We have an optimization for the root frame but DOMIntersectionObserver
keeps its rects relative to `target`. So we only need to do the
expensive transform for IB splits / fragmented flows.
Differential Revision: https://phabricator.services.mozilla.com/D121214
In the case of reflowing caused by full zoom changes, the mDisplaySize isn't
changed, whereas mMobileViewportSize should be changed.
Differential Revision: https://phabricator.services.mozilla.com/D120190
In the case of reflowing caused by full zoom changes, the mDisplaySize isn't
changed, whereas mMobileViewportSize should be changed.
Differential Revision: https://phabricator.services.mozilla.com/D120190
* Per advice from Emilio on Matrix, I consolidated overflow checks into `ScrollFrameHelper::GetOverflowState()`.
* In `ScrollFrameHelper::ReflowFinished` we detect the condition requring the app to expand the toolbar.
(Hiro, I know that you suggested a second place to detect this. If you feel that it is important enough to add that,
we'd prefer filing a follow-up bug in Layout for that case that your team can follow up on.)
* We then propagate the notification through `PresShell`, up through `PBrowser`, through the `nsWindow`, then into the `GeckoSession`
* We invoke a new method on the `ContentDelegate`. This seemed like the reasonable delegate to use given other existing
callbacks in the similar vein (such as going fullscreen), but let me know if this should go elsewhere.
* We update GVE and JUnit tests to test this.
Differential Revision: https://phabricator.services.mozilla.com/D120499
Emilio Cobos Álvarez
Botond Ballo
Daniel Holbert
Andi-Bogdan Postelnicu
Hiroyuki Ikezoe
Jeff Muizelaar
Matt Woodrow
Cosmin Sabou
Gijs Kruitbosch
Nicklas Boman
Patrick
Jonathan Kew
Emily McDonough
Olli Pettay
Mats Palmgren
Jan Henning
Boris Chiou
Ben Hearsum
Geoff Brown
Kagami Sascha Rosylight
Florian Quèze
Alexandru Michis
Csoregi Natalia
Dorel Luca
Sandor Molnar
Aaron Klotz