While looking at moving the flag around I realized that the only reason
we have FontMetricsProvider and co is because we didn't have access to
the per-document font-prefs cache. That's trivial to fix tho, so do
that and simplify the setup for font queries even more.
Differential Revision: https://phabricator.services.mozilla.com/D157589
AppUnitsPerDevPixelChanged doesn't propagate the change to BrowserParent, thus
`BrowserParent::mDefaultScale` will be stale. UIResolutionChangedInternal
propagates the change into BrowserParent properly so that the `mDefaultScale`
will be properly updated.
Another approach is to observe preference changes in BrowserParent itself, but
observing layout specific preferences, "layout.css.dpi" or
"layout.css.devPixelsPerPx" in BrowserParent is a bit odd.
Without this change D155946 makes fixed-width-viewport-inflation.html fail
because the test changes "layout.css.devPixelsPerPx" value.
Differential Revision: https://phabricator.services.mozilla.com/D157266
AppUnitsPerDevPixelChanged doesn't propagate the change to BrowserParent, thus
`BrowserParent::mDefaultScale` will be stale. UIResolutionChangedInternal
propagates the change into BrowserParent properly so that the `mDefaultScale`
will be properly updated.
Another approach is to observe preference changes in BrowserParent itself, but
observing layout specific preferences, "layout.css.dpi" or
"layout.css.devPixelsPerPx" in BrowserParent is a bit odd.
Without this change D155946 makes fixed-width-viewport-inflation.html fail
because the test changes "layout.css.devPixelsPerPx" value.
Depends on D156266
Differential Revision: https://phabricator.services.mozilla.com/D157266
This patch is for adding an untyped marker for when a theme change occurs. Previously we could not get a payload from untyped markers but now we can.
Differential Revision: https://phabricator.services.mozilla.com/D156606
As per spec, see https://drafts.csswg.org/css-color-adjust/#color-scheme-effect:
> In order to preserve expected color contrasts, in the case of embedded
> documents typically rendered over a transparent canvas (such as
> provided via an HTML iframe element), if the used color scheme of the
> element and the used color scheme of the embedded document’s root
> element do not match, then the UA must use an opaque canvas of the
> Canvas color appropriate to the embedded document’s used color scheme
> instead of a transparent canvas.
After bug 1782596 we were using the preferred rather than used
color-scheme, which is the right thing to do for prefers-color-scheme,
but not for the canvas background.
Differential Revision: https://phabricator.services.mozilla.com/D155831
We generate the nsPresContext for the cloned document after cloning the
elements, for printing. This makes the updating of the responsive source
failed because we don't have nsPresContext when binding it to the cloned
doucment tree. Therefore, we hit the assertion in the microtask which
trying to load the image for the cloned HTMLImageElement, after dropping
nsAutoScriptBlocker.
This can be avoided by notifying the media feature values changed for
HTMLImageElement synchronously, and so we update the responsive source
once its nsPresContext is created, rather than waiting for flushing the
pending media feature values changed, which may happen after the microtasks.
Differential Revision: https://phabricator.services.mozilla.com/D156020
Only GeckoMVMContext really needs the flush, to measure scrolled height
afterwards. Do that explicitly.
This shouldn't change behavior, for the most part; there was a preload
test that relied on the flush when changing DPI to start a run really
clean, but other than that this looks green on try.
Should at best be neutral (just code clean-up), or be a performance
improvement.
In a follow-up, we can possibly remove the DelayedResize code from the
view manager, though I need to think how to possibly coalesce the MVM
reflows, so let's not do that yet.
Differential Revision: https://phabricator.services.mozilla.com/D155385
Only GeckoMVMContext really needs the flush, to measure scrolled height
afterwards. Do that explicitly.
This shouldn't change behavior, for the most part; there was a preload
test that relied on the flush when changing DPI to start a run really
clean, but other than that this looks green on try.
Should at best be neutral (just code clean-up), or be a performance
improvement.
In a follow-up, we can possibly remove the DelayedResize code from the
view manager, though I need to think how to possibly coalesce the MVM
reflows, so let's not do that yet.
Differential Revision: https://phabricator.services.mozilla.com/D155385
The ColorSchemeMode::Preferred change doesn't make a difference (that
is, always use the preferred one), since when we only propagate from
top's embedder the embedder is chrome, which always has the preferred
color-scheme.
Differential Revision: https://phabricator.services.mozilla.com/D154931
This has the side effect of firing the media query list change event for
printing, but it also improves the print emulation on DevTools, which is
an extra win!
Differential Revision: https://phabricator.services.mozilla.com/D154906
This has the side effect of firing the media query list change event for
printing, but it also improves the print emulation on DevTools, which is
an extra win!
Differential Revision: https://phabricator.services.mozilla.com/D154906
This lets users e.g. print-to-scale where it matters.
Custom margins are still clamped to unwriteable margins, even when all zeroes,
to avoid impacting user-specified & persisted margins.
Differential Revision: https://phabricator.services.mozilla.com/D152900
Before this change, BrowserChild::RecvUIResolutionChanged calls
UIResolutionChangedSync first, then updates CV bounds. With the setup, when
UIResolutionChangedInternal gets called, the CV bounds hasn't yet been updated
so that UpdateSizesBeforeReflow doesn't get the proper metrics.
This change consists of three parts;
1) Use UIResolutionChangedSync instead of UIResolutionChanged in
nsDocumentViewer::SetBoundsWithFlags which calls
nsPresContext::AppUnitsPerDevPixel which needs to be actually updated by
UIResolutionChangedSync.
2) Move the UIResolutionChangedSync call in RecvUIResolutionChanged after
the SetPositionAndSize in the function.
3) Add a UpdateSizesBeforeReflow call in UIResolutionChangedInternal
As for 1), nsDocumentViewer::SetBoundsWithFlags calls
nsPresContext::AppUnitsPerDevPixel so that UIResolutionChangedInternal needs to be
called synchronously rather than asynchronously.
As for 2), SetPositionAndSize gets called only if the BrowserChild size is changed,
so we need to call UIResolutionChangedSync in other cases.
Differential Revision: https://phabricator.services.mozilla.com/D153687
This is far from fully perfect (specially when dealing with nested
containers, we need to be smarter when updating there), but it's
incremental progress.
Differential Revision: https://phabricator.services.mozilla.com/D151496
This is far from fully perfect (specially when dealing with nested
containers, we need to be smarter when updating there), but it's
incremental progress.
Differential Revision: https://phabricator.services.mozilla.com/D151496
And remove one unused caller.
This might change behavior of some selection contrast checks and backplating
which will potentially use the right background-color after this patch. The
next patch ensures this is also accounted for for scrollbars.
Unfortunately selection contrast checks are non-trivial to test because we only
do the contrast check with system colors, and we'd need a default selection
color close to the highlight color to do this.
Differential Revision: https://phabricator.services.mozilla.com/D151017
This patch merges FontFaceSetImpl and gfxUserFontSet into the same
class. This reduces the level of indirection and in theory makes it
easier to manage future threading issues.
Differential Revision: https://phabricator.services.mozilla.com/D147817
This patch aims to split the implementation details of FontFace(Set)
into FontFace(Set)Impl classes. The Impl variants have threadsafe
refcounting and are intended to be the basis for worker support for
FontFace(Set). We need threadsafe objects to pass around because parts
of the stack can only run on the main thread (network loading of font
data, graphics initialization of a font) even if the FontFace(Set)
itself lives on a DOM worker thread. Given the DOM facing objects are
cycle collected, we need additional indirection to support this use
case.
This patch should be a non-functional change.
Differential Revision: https://phabricator.services.mozilla.com/D147505
This patch merges FontFaceSetImpl and gfxUserFontSet into the same
class. This reduces the level of indirection and in theory makes it
easier to manage future threading issues.
Differential Revision: https://phabricator.services.mozilla.com/D147817
This patch aims to split the implementation details of FontFace(Set)
into FontFace(Set)Impl classes. The Impl variants have threadsafe
refcounting and are intended to be the basis for worker support for
FontFace(Set). We need threadsafe objects to pass around because parts
of the stack can only run on the main thread (network loading of font
data, graphics initialization of a font) even if the FontFace(Set)
itself lives on a DOM worker thread. Given the DOM facing objects are
cycle collected, we need additional indirection to support this use
case.
This patch should be a non-functional change.
Differential Revision: https://phabricator.services.mozilla.com/D147505
This patch merges FontFaceSetImpl and gfxUserFontSet into the same
class. This reduces the level of indirection and in theory makes it
easier to manage future threading issues.
Differential Revision: https://phabricator.services.mozilla.com/D147817
This patch aims to split the implementation details of FontFace(Set)
into FontFace(Set)Impl classes. The Impl variants have threadsafe
refcounting and are intended to be the basis for worker support for
FontFace(Set). We need threadsafe objects to pass around because parts
of the stack can only run on the main thread (network loading of font
data, graphics initialization of a font) even if the FontFace(Set)
itself lives on a DOM worker thread. Given the DOM facing objects are
cycle collected, we need additional indirection to support this use
case.
This patch should be a non-functional change.
Differential Revision: https://phabricator.services.mozilla.com/D147505
This allows us to access these prefs off the main thread, e.g. for DOM
workers using OffscreenCanvasRenderingContext2D's text methods.
Differential Revision: https://phabricator.services.mozilla.com/D150124
This in-out parameter business used to be necessary (bug 1249279), but
we don't propagate the new widget scale to remote documents (which are
the common case now) and we seem to be doing just fine without that, so
I'm not sure why this would be needed anymore.
Also simplify some unit conversions while at it.
Differential Revision: https://phabricator.services.mozilla.com/D149032
This is reasonably straight-forward and should allow us change the
desired behavior on platforms if / when we need.
Also, this adds tests for the feature by using the relevant float pref
(though we can't easily assert the full-zoom behavior because it changes
the size of the reftest window itself).
Differential Revision: https://phabricator.services.mozilla.com/D148902
This is reasonably straight-forward and should allow us change the
desired behavior on platforms if / when we need.
Also, this adds tests for the feature by using the relevant float pref
(though we can't easily assert the full-zoom behavior because it changes
the size of the reftest window itself).
Differential Revision: https://phabricator.services.mozilla.com/D148902
GTK already did this, sorta, in a platform-specific way: by hacking in the
scale factor in the CSS screen code. I think this is cleaner, since we have a
centralized place to compute the full zoom in nsPresContext, and that code path
is fairly well tested.
This also would make it trivial to make this text zoom rather than full zoom in
the future, if we wanted (which is probably _technically_ more correct, even
though less pretty less pretty).
This also allows us to remove some hacks where we were undoing the text scale
factor on Linux (since stuff like scrollbars already ignore full zoom).
Depends on D148675
Differential Revision: https://phabricator.services.mozilla.com/D148676
This is mostly an optimization since html/body can't have shadow roots
and we only care about comparing the fullscreen element against those,
but it also avoids the problematic codepath.
The issue is that we call UpdateViewportScrollStylesOverride() in the
middle of UnbindFromTree when the DOM state isn't quite stable.
Before my patch, we only did that once the top layer stack is empty, but
now we do it once for each element we pop, which means that we might hit
this codepath with a fullscreen element mid-unbind.
The following patch fixes it but this seemed worth doing anyways.
Differential Revision: https://phabricator.services.mozilla.com/D148491
This change allows us to remove the `FullZoom` multiplier and fixes text
bounds caclulations in a zoomed page.
Testing: The current browser scroll/bounds tests pass (with the
exception of fission iframes which were already broken).
Differential Revision: https://phabricator.services.mozilla.com/D146507
These need to be atomic so that they can be accessed by canvas code when running on a worker thread
without calling main-thread-only Preferences APIs.
Depends on D144185
Differential Revision: https://phabricator.services.mozilla.com/D144186
This allows popups and sidebars to use the chrome preferred
color-scheme.
This moves the responsibility of setting the content-preferred color
scheme to the appropriate browsers to the front-end (via tabs.css).
We still return the PreferredColorSchemeForContent() when there's no
pres context (e.g., for display:none in-process iframes). We could
potentially move a bunch of the pres-context data to the document
instead, but that should be acceptable IMO as for general web content
there's no behavior change in any case.
Differential Revision: https://phabricator.services.mozilla.com/D142578
This patch is a bit bigger than I'd like, but it's mostly moving code
around to centralize the color/color-scheme decisions we make when
forcing colors.
In practice, the only behavior change should be that when "use system
colors" is false and we force colors, we force a color-scheme that
matches the user-chosen background (via the LookAndFeel::IsDarkColor
check).
That should make sure that text from system colors is light and matches
the user expectations.
Before this patch, we used to force the color-scheme to light, but that
was just so that we ended up looking at mLightColors. Instead, we
achieve that via a separate bit (mForcedLightColorSet, naming up for
debate, not a fan), so that we can use the right system colors
otherwise.
Another alternative I considered is making all non-link system colors
return mDefaultBackground / mDefault depending on whether they are
background / foreground colors. That seemed a lot more work and
potentially a regression in various ways. I think this should be
strictly an improvement instead.
Differential Revision: https://phabricator.services.mozilla.com/D142423
