Bug 1855151 has some example of confusion this causes, and bug 221490
has some more history.
I don't see why chrome://foo/content should be different from
chrome://foo/skin etc, in terms of privileges. I guess in the past this
distinction probably made more sense?
Per discussion in the review comments, we're not touching langpacks (yet).
Differential Revision: https://phabricator.services.mozilla.com/D189232
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
This patch replaces the previous ContractID-based lookup system for protocol
handlers, and replaces it with a new custom system in nsIOService. It will be
pre-populated with non-overridable static protocol handlers using the
StaticComponents infrastructure added in the previous part, and callers can
also dynamically register new protocol handlers at runtime.
This new system is intended to provide access to the default port and
non-dynamic protocol flags off-main-thread, by requiring these values to be
provided up-front as constants, rather than getting them from the xpcom
interface. The data is then guarded by an RWLock.
Callers which look up specific handlers by their contractID are not changed, as
the contract IDs for existing handlers have not been changed, so the lookup
will still succeed.
This change as-implemented breaks the nsGIOProtocolHandler on Linux, as it
removes the special code which would try to use that handler for some
protocols. This will be fixed in a later part by making the
nsGIOProtocolHandler use the dynamic registration APIs to register and
un-register protocol handlers at runtime in response to the GIO pref.
Differential Revision: https://phabricator.services.mozilla.com/D162804
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
This patch replaces the previous ContractID-based lookup system for protocol
handlers, and replaces it with a new custom system in nsIOService. It will be
pre-populated with non-overridable static protocol handlers using the
StaticComponents infrastructure added in the previous part, and callers can
also dynamically register new protocol handlers at runtime.
This new system is intended to provide access to the default port and
non-dynamic protocol flags off-main-thread, by requiring these values to be
provided up-front as constants, rather than getting them from the xpcom
interface. The data is then guarded by an RWLock.
Callers which look up specific handlers by their contractID are not changed, as
the contract IDs for existing handlers have not been changed, so the lookup
will still succeed.
This change as-implemented breaks the nsGIOProtocolHandler on Linux, as it
removes the special code which would try to use that handler for some
protocols. This will be fixed in a later part by making the
nsGIOProtocolHandler use the dynamic registration APIs to register and
un-register protocol handlers at runtime in response to the GIO pref.
Differential Revision: https://phabricator.services.mozilla.com/D162804
This prevents copies and avoids the hack we have to avoid this, which
right now is using nsDependent{C,}String.
Non-virtual actors can still use `nsString` if they need to on the
receiving end.
Differential Revision: https://phabricator.services.mozilla.com/D152519
This patch won't actually build, because a few bits of code are used
for both nsIFactory::createInstance and static components, and static
components are not fixed until the next patch.
The first place is nsLoadGroupConstructor, which uses an nsIFactory
macro to create a static component constructor. (This could be worked
around by expanding the macro to the state before this patch.)
The other issue is that nsAppShellConstructor is used in an nsIFactory
on OSX, but as a static component on all other platforms. This could
be worked around by wrapping nsAppShellConstructor in an adaptor that
passes in the extra null argument to nsAppShellConstructor.
Differential Revision: https://phabricator.services.mozilla.com/D146456
Automatically generated rewrites of all ParamTraits and IPDLParamTraits
implementations in-tree to use IPC::Message{Reader,Writer}.
Differential Revision: https://phabricator.services.mozilla.com/D140004
Automatically generated path that adds flag `REQUIRES_UNIFIED_BUILD = True` to `moz.build`
when the module governed by the build config file is not buildable outside on the unified environment.
This needs to be done in order to have a hybrid build system that adds the possibility of combing
unified build components with ones that are built outside of the unified eco system.
Differential Revision: https://phabricator.services.mozilla.com/D122345
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
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
It should be called "Get" rather than "Lookup" because it returns
UserDataType. "Add" is called "Insert" in the other methods.
Differential Revision: https://phabricator.services.mozilla.com/D105470
