The motivation here is that we will want to call CSSTransition specific
functions, e.g. updating the start value of a given CSSTransition with
the latest value of the CSSTransition on the compositor, from somewhere
not in layout/style. Unfotunately nsTransitionManager.h is not exposed
and we will never want to expose it since it's purely for layout/style
stuff.
Depends on D73570
Differential Revision: https://phabricator.services.mozilla.com/D73571
We currently generate absolute paths in all of our XPIDL-generated
source files, which is not so great for several reasons (deterministic
generation of files across machines, Searchfox analysis logic, shared
compilation caches, etc.). Let's generate paths that still indicate
where you should be looking, but are identical across compilations,
objdirs, etc.
Differential Revision: https://phabricator.services.mozilla.com/D73747
It's not like we're going to change behavior here anytime soon anymore
(other than removing XUL usage), and the helpfulness of the warning has
probably decreased with time.
But maybe I'm missing a reason why it should be kept around?
Differential Revision: https://phabricator.services.mozilla.com/D73544
Installed privileged addons in GeckoView sometimes need to send messages from
content scripts. Today we use the in-memory flag `ALLOW_CONTENT_MESSAGING` to
allow a specific built-in addon to send messages from content scripts, but for
installed extensions we need a way to persist this flag.
To do this, this patch introduces a new privileged permission
`nativeMessagingFromContent`, when this permission is present in the manifest,
the addon will be allowed to send native messages from content scripts (note:
the addon will also need `nativeMessaging` as usual).
When the permission is not present, any attempt to send a native message from a
content script will result in an error, similarly to what happens before this
patch.
Differential Revision: https://phabricator.services.mozilla.com/D72976
Sometimes extensions call tabs.create immediately on startup. In that case the
delegate may not be attached yet. To avoid losing these messages we store them
until a delegate is attached.
This also includes a refactoring to unify behavior for delegates. Eventually I
want to factor out delegates similarly to what happens in GeckoSession today.
Differential Revision: https://phabricator.services.mozilla.com/D72975
We use this to send a default action to the embedder, but if no one is
listening there's no point, and it causes problems in tests because sometimes
the delegate is attached / reattached too quickly and the second delegate will
end up getting two messages by mistake.
Differential Revision: https://phabricator.services.mozilla.com/D72974
At the time this code was written, JavaScript JIT entry trampolines were
emitting EnterJIT label frames that carried a stack address. From this stack
address, register values could be recovered that would allow native stack
unwinding to resume after getting lost in JIT code.
The EnterJIT label frame was removed in bug 1057082.
Differential Revision: https://phabricator.services.mozilla.com/D73939
In rare cases, a dispatch may fail (e.g., threads are shutting down), we should handle this failure by rejecting the promise on the spot.
Depends on D73791
Differential Revision: https://phabricator.services.mozilla.com/D73792
It is not necessary to dispatch another task to the main thread to resolve/reject a MozPromiseHolder, because wherever this happens, the attached `Then` will do its own dispatch to the main thread.
Also, this removes a dispatch that could potentially fail, leaving the promise unfulfilled.
Depends on D73790
Differential Revision: https://phabricator.services.mozilla.com/D73791
While gathering profiles from child processes, some actions (e.g., shutting down, restarting the profiler) may reset the gathering operation.
In this case we must ensure that the promise is rejected if not already fulfilled, so that anyone waiting on it won't be blocked forever (and MozPromise enforces it in a MOZ_DIAGNOSTIC_ASSERT).
Differential Revision: https://phabricator.services.mozilla.com/D73790
The spatial node index and clip chain id are no longer directly
related concepts, since they now exist in different representations
(the spatial tree and clip store).
Removing the grouping of these during scene building simplifies
some work in progress to refactor how WR internally represents
clips, in order to allow future optimization work.
Differential Revision: https://phabricator.services.mozilla.com/D73187