And use nsID::ToProvidedString(...) method when suitable.
This naturally fixes a memory leak in dom/fetch/FetchParent.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D167606
And use nsID::ToProvidedString(...) method when suitable.
This naturally fixes a memory leak in dom/fetch/FetchParent.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D167606
Actually, we can get Android release version from JNI generator, so it is
unnecessary to use `AndroidBridge` to get it.
Also, this cleans up unused AndroidBridge functions.
Differential Revision: https://phabricator.services.mozilla.com/D164431
This adds a new set of options to static components.conf files to allow
specifying the protocol flags and default ports of a protocol handler, and
generates a separate table just for this purpose.
This will be used in the next part as part of replacing the existing protocol
handler lookup infrastructure.
Differential Revision: https://phabricator.services.mozilla.com/D162803
This adds a new set of options to static components.conf files to allow
specifying the protocol flags and default ports of a protocol handler, and
generates a separate table just for this purpose.
This will be used in the next part as part of replacing the existing protocol
handler lookup infrastructure.
Differential Revision: https://phabricator.services.mozilla.com/D162803
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
Several widget contracts use different implementations in the parent and
content processes. Since the static registration system builds its hashtable
at compile time rather than runtime, it doesn't support different contract IDs
per process. It could make the decision at lookup time, but given how rarely
it's needed, I don't think it would be worth the complexity.
This patch updates the widget components that need different implementations
in the parent and content process to register separate contracts for each
implementation, and a third stub contract which forwards to the appropriate
implementation depending on which process it's used in. The implementation
entries restrict their usage to the process they are meant to be used in.
Differential Revision: https://phabricator.services.mozilla.com/D149436
Several widget contracts use different implementations in the parent and
content processes. Since the static registration system builds its hashtable
at compile time rather than runtime, it doesn't support different contract IDs
per process. It could make the decision at lookup time, but given how rarely
it's needed, I don't think it would be worth the complexity.
This patch updates the widget components that need different implementations
in the parent and content process to register separate contracts for each
implementation, and a third stub contract which forwards to the appropriate
implementation depending on which process it's used in. The implementation
entries restrict their usage to the process they are meant to be used in.
Differential Revision: https://phabricator.services.mozilla.com/D149436
Several widget contracts use different implementations in the parent and
content processes. Since the static registration system builds its hashtable
at compile time rather than runtime, it doesn't support different contract IDs
per process. It could make the decision at lookup time, but given how rarely
it's needed, I don't think it would be worth the complexity.
This patch updates the widget components that need different implementations
in the parent and content process to register separate contracts for each
implementation, and a third stub contract which forwards to the appropriate
implementation depending on which process it's used in. The implementation
entries restrict their usage to the process they are meant to be used in.
Differential Revision: https://phabricator.services.mozilla.com/D149436
Several widget contracts use different implementations in the parent and
content processes. Since the static registration system builds its hashtable
at compile time rather than runtime, it doesn't support different contract IDs
per process. It could make the decision at lookup time, but given how rarely
it's needed, I don't think it would be worth the complexity.
This patch updates the widget components that need different implementations
in the parent and content process to register separate contracts for each
implementation, and a third stub contract which forwards to the appropriate
implementation depending on which process it's used in. The implementation
entries restrict their usage to the process they are meant to be used in.
Differential Revision: https://phabricator.services.mozilla.com/D149436
Andrew McCreight
serge-sans-paille
Norisz Fay
Sylvestre Ledru
Makoto Kato
Nika Layzell
Marian-Vasile Laza
Marco Castelluccio
Kagami Sascha Rosylight
Emilio Cobos Álvarez
Andi-Bogdan Postelnicu
Kris Maglione
Mozilla Releng Treescript
Noemi Erli
criss