Sorry this is not a particularly easy patch to review. But it should be
mostly straight-forward.
I kept Document::Dispatch mostly for convenience, but could be
cleaned-up too / changed by SchedulerGroup::Dispatch. Similarly maybe
that can just be NS_DispatchToMainThread if we add an NS_IsMainThread
check there or something (to preserve shutdown semantics).
Differential Revision: https://phabricator.services.mozilla.com/D190450
This method isn't actually safe to run off-main-thread yet, as nsIPrincipal
manipulation isn't being made threadsafe until a later part, however it can be
called off-main-thread when creating a new content principal with a Blob URL
spec.
Differential Revision: https://phabricator.services.mozilla.com/D163031
This removes all implementations of these types. Some implementations in JS
code were also removed in the previous part, when updating tests to use
`Services.io.registerProtocolHandler`.
Code which used to access these members should go through the IOService now
instead.
Differential Revision: https://phabricator.services.mozilla.com/D162805
These implementations of nsIProtocolHandlerWithDynamicFlags were actually
always returning the same flags, so can be simplified.
Differential Revision: https://phabricator.services.mozilla.com/D162800
This removes all implementations of these types. Some implementations in JS
code were also removed in the previous part, when updating tests to use
`Services.io.registerProtocolHandler`.
Code which used to access these members should go through the IOService now
instead.
Differential Revision: https://phabricator.services.mozilla.com/D162805
These implementations of nsIProtocolHandlerWithDynamicFlags were actually
always returning the same flags, so can be simplified.
Differential Revision: https://phabricator.services.mozilla.com/D162800
This does a somewhat-shallow removal of the argument from the implementation
and all call-sites. Removing it from StructuredCloneData's serialization is
handled in the next part, as it is more widely used and complex.
Differential Revision: https://phabricator.services.mozilla.com/D148531
If run late in shutdown, we cannot rely on any of our normal infrastructure to be still in place. This patch collects a series of additional guards to avoid potential crashes.
Not all of them might ever been hit, but there is no harm in additional checks as this is not performance critical at all.
Differential Revision: https://phabricator.services.mozilla.com/D143687
This basically reverts the changes in 5caa81103c00 (bug 1435671). In that bug
we switched from having a templated method to using a templated function
that returned a lambda because the templated method caused a binary size
regression on windows (MSVC). Since Firefox 67 we no longer support MSVC.
Using a lambda also required capturing the arguments by value, so it was
slightly inefficient.
This patch removes NS_MutatorMethod and makes the Apply method a template.
This improves perfomance as we can just pass the arguments to the called
function, without worrying about needing to copy them.
Since MSVC is not supported anymore, and clang and gcc didn't report a
binary size regression, this is a much better solution.
Differential Revision: https://phabricator.services.mozilla.com/D122081
This basically reverts the changes in 5caa81103c00 (bug 1435671). In that bug
we switched from having a templated method to using a templated function
that returned a lambda because the templated method caused a binary size
regression on windows (MSVC). Since Firefox 67 we no longer support MSVC.
Using a lambda also required capturing the arguments by value, so it was
slightly inefficient.
This patch removes NS_MutatorMethod and makes the Apply method a template.
This improves perfomance as we can just pass the arguments to the called
function, without worrying about needing to copy them.
Since MSVC is not supported anymore, and clang and gcc didn't report a
binary size regression, this is a much better solution.
Differential Revision: https://phabricator.services.mozilla.com/D122081
Note that this patch only transforms the use of the nsDataHashtable type alias
to a directly equivalent use of nsTHashMap. It does not change the specification
of the hash key type to make use of the key class deduction that nsTHashMap
allows for in some cases. That can be done in a separate step, but requires more
attention.
Differential Revision: https://phabricator.services.mozilla.com/D106008
This makes the naming more consistent with other functions called
Insert and/or Update. Also, it removes the ambiguity whether
Put expects that an entry already exists or not, in particular because
it differed from nsTHashtable::PutEntry in that regard.
Differential Revision: https://phabricator.services.mozilla.com/D105473
