What caused the issue was that nsMenuPopupFrame::MoveTo didn't account
for the change in bug 312891. But our context menu / popup positioning
code can be much simpler if we account for the context menu offset
before-hand as an extra horizontal / vertical margin in all directions.
Then we don't need to special-case it at all.
Differential Revision: https://phabricator.services.mozilla.com/D140263
What caused the issue was that nsMenuPopupFrame::MoveTo didn't account
for the change in bug 312891. But our context menu / popup positioning
code can be much simpler if we account for the context menu offset
before-hand as an extra horizontal / vertical margin in all directions.
Then we don't need to special-case it at all.
Differential Revision: https://phabricator.services.mozilla.com/D140263
WeakRefs are exposed to the user so anyone can create CCWs to WeakRefs. Don't
assume that a nuked WeakRef CCW is one that we created but get it's target to
find which zone to look it up in.
Differential Revision: https://phabricator.services.mozilla.com/D140044
Also include the raster scale in the PictureKey, so that WR will
invalidate when everything is the same apart from the raster
scale (was causing the included wrench reftest to not re-render).
Differential Revision: https://phabricator.services.mozilla.com/D140282
Don't clone the whole message we receive as a result of a console API call, but select
properties that are being used on the client.
As a result, we're not sending some properties anymore (`functionName`, `addonId`, `workerType`),
and we also don't include some properties when they are falsy and wouldn't bring
any benefit (`counter`,`timer`, `private`, `prefix`, `stacktrace`)
Hopefully this helps save some cycle since we're not cloning an object, but also in the
JSActor communication since the packet we need to send is smaller.
We do similar changes to the webconsoleActor method, which is still used in non
fission scenarios, and remove WebConsoleUtils.cloneObject which is no longer used.
Differential Revision: https://phabricator.services.mozilla.com/D139686
This allows multiple threads to access ThreadRegistrations through the thread registry, as long as the registry itself is not modified. So in particular, ThreadRegistrations are guaranteed to stay alive as long as a non-exclusive lock is held.
This ensures cross-thread markers are not blocked while the sampler is running.
Differential Revision: https://phabricator.services.mozilla.com/D139917
This is a profiler-specific shared lock (aka readers-writer lock) implemented on top of RWLockImpl.
Similar to BaseProfilerMutex, it records which thread is currently holding the exclusive lock.
Differential Revision: https://phabricator.services.mozilla.com/D139916
This new method is being used in DevTools code to replace the usage
that was made of `getOwnPropertyNames` only to retrieve the length
property of the returned array.
Differential Revision: https://phabricator.services.mozilla.com/D139709
This patch is to delay starting `UntrustedModulesProcessor` to avoid
processing a massive amount of loaded modules in the browser process
during startup.
To achive that, this patch introduces "unblock-untrusted-modules-thread"
notification. Before the notification, `UntrustedModulesProcessor` is
created but marked as not ready. This means the processor does not
go beyond `ScheduleNonEmptyQueueProcessing`. Once the notification is
observed, we propagate it to all existing child processes, and afterward
`UntrustedModulesProcessor` in new processes will be marked ready from
the beginning.
Differential Revision: https://phabricator.services.mozilla.com/D140123
`nsIFrame::IsRelativelyPositioned()` tests "position:relative" or
"position:sticky", but its naming is misleading until you've dug into the
underlying helper `nsStyleDisplay::IsRelativelyPositionedStyle()`.
Differential Revision: https://phabricator.services.mozilla.com/D140273
This patch is to delay starting `UntrustedModulesProcessor` to avoid
processing a massive amount of loaded modules in the browser process
during startup.
To achive that, this patch introduces "unblock-untrusted-modules-thread"
notification. Before the notification, `UntrustedModulesProcessor` is
created but marked as not ready. This means the processor does not
go beyond `ScheduleNonEmptyQueueProcessing`. Once the notification is
observed, we propagate it to all existing child processes, and afterward
`UntrustedModulesProcessor` in new processes will be marked ready from
the beginning.
Differential Revision: https://phabricator.services.mozilla.com/D140123
The signature for GMPInit should have a const arg. This is missing for the fake
plugin here, and that is potentially problematic (if for no other reason than it
breaks UBSan checking of functions). Given that the function doesn't do anything
with its arg for the fake plugin, we can trivially make it const.
Differential Revision: https://phabricator.services.mozilla.com/D139906
We use webgl::RaiiShmem in a few places to read in pixel buffers from a
call to the compositor process. Shmems might fail to be mapped into our
process, probably due to virtual memory constraints, and we should check
for that condition.
Depends on D136355
Differential Revision: https://phabricator.services.mozilla.com/D136365
This allows multiple threads to access ThreadRegistrations through the thread registry, as long as the registry itself is not modified. So in particular, ThreadRegistrations are guaranteed to stay alive as long as a non-exclusive lock is held.
This ensures cross-thread markers are not blocked while the sampler is running.
Differential Revision: https://phabricator.services.mozilla.com/D139917
This is a profiler-specific shared lock (aka readers-writer lock) implemented on top of RWLockImpl.
Similar to BaseProfilerMutex, it records which thread is currently holding the exclusive lock.
Differential Revision: https://phabricator.services.mozilla.com/D139916