This combines the multiple fields or variants which were previously used to
track sided types like protocol types into a single field wrapped with a
SideVariant.
This will be used in the next part to avoid the need for default constructors
for actor types allowing the proper types to be used.
Differential Revision: https://phabricator.services.mozilla.com/D168879
As mentioned in the previous patch, this patch introduces tracking and shutdown of scriptloaders in
the case that we have multiple scriptloaders involved in module loading.
Differential Revision: https://phabricator.services.mozilla.com/D171686
Earlier, we introduced GetBaseURI to the module loader. This allows us to get the BaseURI for a
dynamic import even after the importing script/module's ScriptLoader has been cleaned up. However,
we now need to be able to handle the case where we need to run the dynamic import and load it. In
order to do this, we need to create a scriptloader configured for dynamic import. The most important
difference between this scriptloader and the one that is normally used for script loading in workers
is that we *do not have a syncLoopTarget* to which we return. There are a couple of reasons for
this:
* Dynamic import (and modules in general) relies on the event loop to resolve. If we create a
syncLoop here, we will end up pausing execution, and this breaks the StartModuleLoad algorithm. We
will never complete and the result will be that we are in the wrong state when we return here.
* We do not have perfect knowledge of the future, so we cannot keep the existing script loader alive
in the case that it might be used for loading in the future.
* We cannot migrate the ModuleLoader to not use sync loading without significantly changing other
aspects of how loading scripts on workers works. This becomes particularily evident with error
handling
(https://searchfox.org/mozilla-central/rev/00ea1649b59d5f427979e2d6ba42be96f62d6e82/dom/workers/WorkerPrivate.cpp#383-444),
and in addition, for reasons I wasn't able to discern, using the CurrentEventTarget results in hard
to identify errors. When there is time to investigate this fully, the ModuleLoader may move away
from using a syncLoop itself.
For now, all main-script loads (whether they are modules or classic scripts) will use the sync loop,
and all dynamic imports will create a new script loader for their needs that is not using the sync
loop. The book keeping for this is in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D171685
This change addresses the second issue around worker shutdown with infinitely running dynamic
imports: As the event loop is prevented from running when the worker is dying, we do not want to
delegate to the event loop in this case. This case always has a failing promise. Since this is a
failure case related to the worker dying, we stop running code, rather
than waiting for a tick (that never comes) from the event loop.
Differential Revision: https://phabricator.services.mozilla.com/D171684
When running an infinitely-looping dynamic import, it is possible for the module loader to still be
holding on to that module at shutdown. Shutdown on the worker means that we will no longer run the
event loop, which will execute the dynamic import promises necessary to clear the global. The result
is that the global is kept alive. By calling `Shutdown()` we prevent this partially. We additionally
need to address the failure in the module code (next patch).
Differential Revision: https://phabricator.services.mozilla.com/D171683
This is a required change for dynamic import on workers, as the ScriptLoader is not guaranteed to
live long enough. Once the initial script loading is finished, and the script has executed, the
scriptloader is cleared and the strong reference to the workerRef is cleared so that shutdown is
possible. The workerRef is required in order to access the worker private safely. In order to
address this, we move the GetBaseURI method to the module loader itself. In the future, we should
remove the script loader interface all together.
Differential Revision: https://phabricator.services.mozilla.com/D171682
We can't add the provenance data to the `installation.first_seen` extra data because it is already at its maximum number of keys. So instead we will add the `installation.first_seen_prov_ext` event which will be sent at the same time as `installation.first_seen` and will contain provenance attribution data in its extras object.
Differential Revision: https://phabricator.services.mozilla.com/D172520
On the server side, this patch introduces:
* a new "tracer" Target Scope actor to start and stop tracing per target
* a new TRACING_STATE resource in order to report to the client when we start/stop tracing and with which log method.
On the frontend side, this patch introduces:
* a global tracer button, which will enable/disable tracing for all targets/threads
all at once.
* a global header, similar to pause, reporting if any target is tracing or not.
The header reuses the pause header and we may want to followup to better coordinate case
where we pause and trace at the same time. Only one of the two states is displayed.
We may want to followup here to be able to trace only one target and see the state per target.
Differential Revision: https://phabricator.services.mozilla.com/D163614
This renames nsMacCursorManager to MOZDynamicCursor and makes it implement NSCursor.
We also install a cursor rect which covers the entire ChildView and which refers
to the MOZDynamicCursor singleton.
With the help of the cursor rect, the -[NSCursor set] implementation is now called
at the right times.
Here's a profile which contains the stacks under which -[MOZDynamicCursor set]
is now called: https://share.firefox.dev/3yEXLsC
Differential Revision: https://phabricator.services.mozilla.com/D172484
Happy code deletion day!
nsMacCursor was used so that animated cursors could be treated like non-animated cursors.
But we don't have animated cursors anymore! Nothing calls -[nsMacCursor cursorWithFrames:type:].
Depends on D172479
Differential Revision: https://phabricator.services.mozilla.com/D172480
This moves creating FormAutoCompleteResult out of the controller and into SearchSuggestions.
SearchSuggestions is only used for the autocomplete interface and so this simplifies the work for content search and address bar.
Differential Revision: https://phabricator.services.mozilla.com/D172372
