No change in behavior here; this is to prepare for offscreen-canvas workers
to be able to access the pref (following patch).
Depends on D181636
Differential Revision: https://phabricator.services.mozilla.com/D181637
We have more readable and faster versions (that just omit the namespace
arg).
Mostly done via sed, with a couple helpers to use the faster lookups
where possible.
Differential Revision: https://phabricator.services.mozilla.com/D181795
Usually this happened because the frontend never specified any zoom for
these, but once we started honoring the system scale factor, well...
For printing, we should use the print scale factor to determine
css-to-device scale. I assume text scale we could keep, but that doesn't
seem worth it and it seems preferable to keep stuff consistent between
zoom and OS text scale / zoom.
I don't know of another reasonable way to test this other than this (and
it kinda sucks), but I'm open to ideas.
Differential Revision: https://phabricator.services.mozilla.com/D177709
That's how we do it for all other platforms. Do this rather than via a
custom mostly-untested pref, which allows us to simplify text zoom
handling.
Differential Revision: https://phabricator.services.mozilla.com/D177062
Currently these functions and related variables are based on
FirstContentfulPaint, however the naming are too generic. With the
LargestContentfulPaint implementation, they will not only
handle paints for FirstContentfulPaint but also LargestContentfulPaint,
so we need to rename them.
Differential Revision: https://phabricator.services.mozilla.com/D151077
This comes from bug 890195, and it was superseded by bug 1575097.
This isn't used for anything anymore, and we can remove the otherwise unused
MediaFeatureChangeReason flag as well.
Differential Revision: https://phabricator.services.mozilla.com/D174492
For pointer-type getters, we have a convention that a "Get" prefix implies
"warning, this might return null" , whereas lack-of-a-"Get" implies that the
return value is guaranteed to be non-null.
In the case of this `GetBidiEngine` API, this convention doesn't directly apply
since the return value isn't pointer-typed. But it's still backed by a
dynamically-allocated resource which we dereference at the return statement,
and some of the callers take the pointer-value of what's returned and pass that
along elsewhere. So it's helpful (and more concise) to drop "Get" to convey
that yes, we're sure the returned thing is indeed a real object.
Differential Revision: https://phabricator.services.mozilla.com/D172301
We were previously using foo.reset(new) which technically works, but MakeUnique
is preferred, for reasons documented in UniquePtr.h, under "There are various
benefits to using MakeUnique instead of |new| expressions."
Differential Revision: https://phabricator.services.mozilla.com/D172300
Just like how we handle the CSSAnimation and CSSTransition. We use
TimelineCollection to store the named progress timeline objects created
by scroll-timeline-name and view-timeline-name, and reuse
ElementAnimationData to handle the life time of TimelineCollection.
Also, introduce TimelineManager to update timelines generated by CSS.
We add one test which mutates the scroll-timeline-axis to make sure we
restyle the animations associtated with the existing timelines. It will
be passed when we start to use the new framework, in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D169271
This is in order to make nsPresContext::UseOverlayScrollbars() thread-safe for
stylo usage.
Document::GetBrowsingContext() does ref-counting of main-thread-only
objects, and we don't want that.
Similarly nsPresContext::Theme() mutates the pres context which is not
something we can do from multiple threads.
Reviewed in: https://phabricator.services.mozilla.com/D168148
For that we need to:
* Make GetDPIRatioForScrollbarPart thread-safe: This was using the
widget for bug 1727289, but just looking at the print preview scale
is enough to fix that.
* Make nsPresContext::UseOverlayScrollbars() thread-safe: We store the
RDM pane stuff in the pres context.
The rest is pretty straight-forward.
Differential Revision: https://phabricator.services.mozilla.com/D168148
Let the caller addref it if needed.
I wrote this because I wanted to make some code dealing with it
thread-safe, but I ended up writing a less sketchy solution. However I
still think this is worth it.
It seems this only returns an already_AddRefed because before it used to
be an XPCOM-ish thing where the widget was returned as an out-param.
For now it doesn't change behavior but there are some callers that would
benefit from having less addref/release calls if they only need to read
simple stuff from the widget.
Differential Revision: https://phabricator.services.mozilla.com/D168141
Instead of keeping a set of frames to update, keep a depth-ordered frame
list. Factor out the DirtyRootList for this.
Make sure that we're updating ancestor containers before children, and
make sure to store the last container state even if we end up not
updating (due to the element being in mUpdatedContainerQueryContents),
so that following layouts are stable.
This fixes the timeout in inline-size-bfc-floats, and the same kind of
instability in auto-scrollbars.html (if you take a profile of that test
you can see us infinitely recursing), as well as fixing various other
tests.
It causes a regression in nested-query-containers.html, probably to do with
ib-splits (since it's a block inside an inline and so on, and the frame
tree depth doesn't match the content tree depth, most likely). That
might need extra tweaks but it doesn't seem terribly concerning, so I'd
rather get this in.
Differential Revision: https://phabricator.services.mozilla.com/D165628
The Element caller only cares about avoiding a flush and can use the
observable parent layout stuff.
The scrollframe one clearly wants the cross-process version according to
the comment.
Differential Revision: https://phabricator.services.mozilla.com/D162477
It was made a bitfield so that we could include style. But then style
containment was removed and the bitfield keeps causing us to do wrong
check (since INLINE_SIZE intersects SIZE).
So just make it an enum. This causes a progression and a test that
failed now times out (which is a pre-existing issue, just like the
pseudo-elements test that times out).
Differential Revision: https://phabricator.services.mozilla.com/D160371
It was made a bitfield so that we could include style. But then style
containment was removed and the bitfield keeps causing us to do wrong
check (since INLINE_SIZE intersects SIZE).
So just make it an enum. This causes a progression and a test that
failed now times out (which is a pre-existing issue, just like the
pseudo-elements test that times out).
Differential Revision: https://phabricator.services.mozilla.com/D160371
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
