The idea behind this specialization is to provide the members which would be on
SideVariant<..> on NotNull<SideVariant<..>>, similar to how pointer-like
methods are available on `NotNull<T>`. This makes the type more ergonomic to
use from callers.
In the next part, this will be used for non-nullable actor members in IPDL
structs and IPDL unions.
Differential Revision: https://phabricator.services.mozilla.com/D168885
For now, this implementation is based on the implementation of the underlying
type, with extra checking that the value is not null before wrapping and
returning.
We may want to swap things around in the future so that types like RefPtr<T>
are deserialized using NotNull<T*> or similar, so that the unnecessary
serialization overhead of tracking nullness is unnecessary, however that is not
implemented in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D168884
This does a few minor improvements:
1. Adds implicit conversions from NotNull to a raw pointer type if supported by
the underlying type, to make it so NotNull<RefPtr<T>> acts more like
RefPtr<T> in some situations.
2. Adds explicit conversion constructors and assignment operators for RefPtr
and nsCOMPtr from NotNull, avoiding conversion ambiguity added by the first
change.
3. Disable conversion constructors on NotNull with SFINAE if they should not be
available, meaning that type traits like std::is_convertible_v interact with
it properly.
Differential Revision: https://phabricator.services.mozilla.com/D168883
This change allows callers of ReadSequenceParam to return a
Maybe<output_iterator> rather than a T* which will be used to fill the
resulting sequence. Both STL collections and std::array have iterators like
this, which can be returned from these methods without dramatically changing
the signature to support types without default constructors.
For types which support output iterators, they will be used for any type
without a trivial default constructor to avoid unnecessary constructor calls
and initialization when deserializing.
Differential Revision: https://phabricator.services.mozilla.com/D168882
Previously, we would always generate a default constructor for IPDL structs
which explicitly initializes every member. This would require members to have
default initializers statically. With the new approach, each member is
individually wrapped with a template parameter which will try to ensure value
initiaization, and the default constructor is implemented with `= default;`.
The default constructor will produce a warning on clang if it is implicitly
deleted, so that warning is also suppressed.
Differential Revision: https://phabricator.services.mozilla.com/D168881
This builds on top of the work in bug 1775062, by using this new signature
everywhere, including IPDL struct members and in/outparams for IPDL messages.
This is done with relatively minimal changes by using two bindings, one of
which is a reference.
Differential Revision: https://phabricator.services.mozilla.com/D168880
This will be useful after part 3 where it will be used as part of implementing
Read based on Maybe for IPDL structs. Without this change, we'd need to copy to
construct an IPDL struct containing a non-default-constructable type.
Differential Revision: https://phabricator.services.mozilla.com/D169268
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
