I thought we didn't support outline-offset on auto-style outline.
The rect we get is already inflated, so we just got to compute the
radius using that.
Differential Revision: https://phabricator.services.mozilla.com/D105125
From GTK 3.24.25 on we have a new API that allows us to savely apply
opaque regions to our own surfaces without risking to freeze GDK.
Differential Revision: https://phabricator.services.mozilla.com/D102835
Expectation to timeout got set in latest synchronization with upstream
repository of web-platform-tests (bug 1692513).
Depends on D105275
Differential Revision: https://phabricator.services.mozilla.com/D105276
Expectation as timeout got set in latest synchronization with upstream
web-platform-tests repository (bug 1692513).
Depends on D105274
Differential Revision: https://phabricator.services.mozilla.com/D105275
Use `{g,s}etFixedSlot()` instead of `{g,s}etReservedSlot()` for consistency with
non-shared array buffers and because it's slightly faster.
Depends on D105207
Differential Revision: https://phabricator.services.mozilla.com/D105208
`AsAnyArrayBuffer()` was only called in a single place in "asm.js". Replace
that call by directly rejecting shared array buffers at the top of `CheckBuffer`.
Depends on D105203
Differential Revision: https://phabricator.services.mozilla.com/D105204
`SharedArrayBufferObject` doesn't define an `isPreparedForAsmJS()` method, so
this method was actually calling itself again.
Depends on D105202
Differential Revision: https://phabricator.services.mozilla.com/D105203
Inline the various `AnyArrayBufferXYZ()` functions into the corresponding
`ArrayBufferObjectMaybeShared` methods.
Drive-by change:
Remove the `buf` variable in `ArrayBufferObjectMaybeShared::dataPointerEither()`
for consistency with the other `ArrayBufferObjectMaybeShared` methods.
Differential Revision: https://phabricator.services.mozilla.com/D105202
There are no code changes, only #include changes.
It was a fairly mechanical process: Search for all "AUTO_PROFILER_LABEL", and in each file, if only labels are used, convert "GeckoProfiler.h" into "ProfilerLabels.h" (or just add that last one where needed).
In some files, there were also some marker calls but no other profiler-related calls, in these cases "GeckoProfiler.h" was replaced with both "ProfilerLabels.h" and "ProfilerMarkers.h", which still helps in reducing the use of the all-encompassing "GeckoProfiler.h".
Differential Revision: https://phabricator.services.mozilla.com/D104588
New headers BaseProfilerLabels.h and ProfilerLabels.h now contain all label-related APIs.
These files were hg-copied from the main headers, to preserve history, and then non-label content was removed from the main headers.
The "RAII" macros were moved to these *ProfilerLabels.h headers, because that's the most-common header in which they're needed. Meta-bug 1681416 will probably move these again as needed.
Differential Revision: https://phabricator.services.mozilla.com/D104587
{Base,}ProfilerMarkers.h can now rely on {Base,}ProfilerState.h (and just one function forward declaration), so they don't need to include {Base,Gecko}Profiler.h anymore.
Thanks to that, {Base,Gecko}Profiler.h can now include {Base,}ProfilerMarkers.h at the top.
Also, BaseProfilingStack.h should not include BaseProfiler.h (include loop, can cause failures) not algorithm (not used).
***
roll up into 2nd patch
Differential Revision: https://phabricator.services.mozilla.com/D104969
New headers BaseProfilerState.h and ProfilerState.h now contain most state-reading APIs.
These files were hg-copied from the main headers, to preserve history, and then chosen declarations were kept only in the relevant header.
This is needed in a following patch, where new headers *ProfilerLabels.h use `profiler_is_active()`.
Differential Revision: https://phabricator.services.mozilla.com/D104968
Depends on D104891
Note: some comments are still not finalized, but I want to flag for review now to start collecting feedback.
See inline comments for areas which should be carefully reviewed.
Differential Revision: https://phabricator.services.mozilla.com/D104394
Depends on D104424
performReload is not a regular configuration option as it is not persisted.
It is rather a flag for a single call to Target::reconfigure.
As we move configuration options outside of the target, it will be easier to drive the reload from the frontend.
The call sites using performReload are quite rare and only found in the netmonitor so it doesn't feel like this
requires a framework solution for now. We add explicit calls to TargetFront::reload() in spots where the netmonitor
used to pass performReload = true.
Differential Revision: https://phabricator.services.mozilla.com/D104891
Depends on D104423
Same as for isJavascriptEnabled in the previous patch.
With the upcoming Configuration actor, updating the configuration should not be on target-scoped API.
Moving the `reconfigure` API to TargetList reduces the required refactors for the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D104424
Depends on D104392
With the Configuration actor the javascript enabled information should no longer be held by the target front.
This abstraction layer in target-list will make the transition easier.
Differential Revision: https://phabricator.services.mozilla.com/D104423
Depends on D104391
This flag will be needed for server side target switching as well.
Introducing it here will allow to update the configuration only on top level targets
Differential Revision: https://phabricator.services.mozilla.com/D104392
