The CSS Box Sizing specification indicates that last remembered sizes
are recorded "at the time that ResizeObserver events are determined and
delivered" [1].
In bug 1807253, we changed the implementation of when proximity to the
viewport of `content-visibility: auto` nodes are determined and of when
resize observations are broadcast, in order to align with the latest
version of the HTML specification [2]. We continue to use an internal
`Document::mLastRememberedSizeObserver` to update last remembered sizes
but it has been causing issues (e.g. bug 1867090 and bug 1880928) and
could be replaced by a direct update before broadcasting resize
observations.
This is what the current patch is doing. The elements currently observed
by `Document::mLastRememberedSizeObserver` are now stored on a
`Document::mElementsWithLastRememberedSize` hashset and a new function
`Document::UpdateLastRememberedSizes` is called before broadcasting
resize observations, and peforms the work of `LastRememberedSizeCallback`
and of `CalculateBoxSize` (with `aBox=Content_box`).
The only behavior change is in the `while(true)` loop from
`DetermineProximityToViewportAndNotifyResizeObservers`: at each step
we update the last remember sizes for elements of arbitrary depth, and
don't use these depths for calculating `shallowestTargetDepth`. This is
fine, since our `LastRememberedSizeCallback` only records current box
sizes without causing significant side effects (e.g. execution of
JavaScript code) that may require a relayout.
[1] https://drafts.csswg.org/css-sizing-4/#last-remembered
[2] https://html.spec.whatwg.org/#update-the-rendering
Differential Revision: https://phabricator.services.mozilla.com/D202571
In order to create less WebRenderLayerScrollData currently we use a deferred transform item
https://searchfox.org/mozilla-central/rev/593c49fa812ceb4be45fcea7c9e90d15f59edb70/gfx/layers/wr/StackingContextHelper.h#82
We don't need a WebRenderLayerScrollData for every transform because a lot of transforms don't contain any ASRs, so the created WebRenderLayerScrollData would be useless.
However this optimization can lead to us creating a lot more WebRenderLayerScrollData later if the transform does contain ASRs. For example, if there is a transform, and then inside that is a ASR, and inside the ASR is a lot of small transforms, we end up having to create a WebRenderLayerScrollData for every little transform which don't contain any ASRs. This is doing the opposite of what the optimization intended.
WebRenderLayerScrollData creation happens during the CreateWebRenderCommands phase, so the display list build phase is complete, and we can tell cheaply if a transform contains any ASRs during display list building. So we just record that and use that to inform our decision about when to defer the transform item or not.
This optimization drastically reduces the total number of WebRenderLayerScrollData that we create during a full run of speedometer3 (summing the number created each paint over every paint). In my testing it went from 12-13k to 2-3k. Mostly subtests fell into two buckets: a single digit number of WebRenderLayerScrollData to begin with and this patch didn't change that, and 100 WebRenderLayerScrollData down to single digits after this patch. So the savings are concentrated in a few subtests that hit the described behaviour above.
I compared a profile before and after this patch of 10 runs of speedometer3, this patch saved 100 samples/ms serializing WebRenderLayerScrollData, which was what I expected based on how long serialization took before the patch combined with how many WebRenderLayerScrollData we were avoiding. The whole run took about 100,000 samples/ms, so this should hopefully be good for about 0.1% improvment. There is also potential savings in other areas outside of serialization step but that was a little harder to measure.
Differential Revision: https://phabricator.services.mozilla.com/D197446
This line used to be
self.content += six.ensure_binary(f) + b"\n"
before bug 1751990, but it was accidentally replaced with something that
turns out not to be equivalent at all, and I missed it during review.
Differential Revision: https://phabricator.services.mozilla.com/D203049
This patch uses mozscreenshot to take a screenshot of the test right up
to the moment of failure. This should be helpful in diagnosing failures
in CI like benchmark tests (which don't output videos like pageload
tests) as well as pageload tests if they fail before visual metrics can
capture a video/screenshot to output.
Differential Revision: https://phabricator.services.mozilla.com/D202634
The ARIA spec requires that, for certain landmark roles with no author-specified
names, user agents must treat such elements as if no role had been provided.
This revision accomplishes that task by carving out an exception in
ARIATransformRole and ComputeARIARole for roles::FORM, similar to the existing
carveout for roles::REGION. This revision also implements a NameIsEmpty function
which is helpful for checking name emptiness (since we do this in a few places)
without leaving a "name" variable on the stack. Finally, this revision updates a
expected WPT failure (by removing it).
Differential Revision: https://phabricator.services.mozilla.com/D202778
The RegExpCompiler stores the flags internally, so there isn't any need to pass them in here. Upstream V8 fixed the API.
Differential Revision: https://phabricator.services.mozilla.com/D201919
In [this commit](https://chromium-review.googlesource.com/c/v8/v8/+/4727690), V8 changed its IsFoo predicates from methods into free functions as part of the Tagged<T> work.
At first I was simply going to move the current implementation, but as I was writing a comment to explain why `bool IsByteArray(Object obj) { return true; }` was not as dumb as it looked, I decided that we could do better.
V8's ByteArrays are managed by the GC, and the typecheck can be done by looking at the map (shape). Our implementation of ByteArray is a length-prefixed array allocated by malloc, so we can't check the type the same way, but in debug builds we can stick a magic number in the header and validate that it hasn't been messed with.
We can use a dedicated MagicValue for the exception we throw when interrupting (which maps closely to V8's approach).
Differential Revision: https://phabricator.services.mozilla.com/D201916
As part of [this bug](https://bugs.chromium.org/p/v8/issues/detail?id=12710) in which they move object definitions back from Torque to C++, V8 added a Tagged<T> wrapper, which stores a pointer that is low-bit tagged (V8's values are either a 0-tagged small integer or a 1-tagged pointer).
We don't have the same object representation, so we just need a transparent wrapper.
Differential Revision: https://phabricator.services.mozilla.com/D201915
This test uses various specified `mask` values that reference example.com. If
we let the masked element render, then we're forced to contact example.com to
try to get the mask, and that causes our test harness to abort (since remote
network connections are forbidden, for stability/safety purposes).
Fortunately the test only cares about parsing/serialization, and isn't testing
rendering at all. So we can use display:none to hide the masked element and
make the network connections unnecessary.
Differential Revision: https://phabricator.services.mozilla.com/D203051
This handles both cases on startup, where an application provided engine is added, or removed from the user's set of engines.
Differential Revision: https://phabricator.services.mozilla.com/D202745
We have two very similar modules right now but with some different behavior:
1. With MOZ_NEW_NOTIFICATION_STORE=True we save the DB via kvstore, which has no shutdown blocker and causes crash when being too late.
2. With MOZ_NEW_NOTIFICATION_STORE=False we save the DB via IOUtils, which does have its shutdown blocker.
Either way there's no shutdown blocker that ensures processing the whole task queue, which poses risk of losing notification data, which is required when notification is clicked by user. This patch adds that.
Unfortunately we don't have a test here as I don't think we have infra for shutdown blocking test.
Differential Revision: https://phabricator.services.mozilla.com/D200042
I reorganized the existing types and added a few comments so that a
reader can match each defined type to a specific Firefox internal object.
Depends on D200552
Differential Revision: https://phabricator.services.mozilla.com/D200932
