Since JSWindowActors don't have direct access to synchronous messaging,
ChromeScript callers are going to need to migrate to asynchronous messaging
and queries instead.
Since there's no comparable API to sendQuery for frame message managers, this
patch adds a stub that uses synchronous messaging, but makes the API appear
asynchronous, and migrates callers to use it instead of direct synchronous
messaging. This will be replaced with a true synchronous API in the actor
migration.
Fortunately, most of the time, this actually leads to simpler code. The
`sendQuery` API doesn't have the odd return value semantics of
`sendSyncMessage`, and can usually just be used as a drop-in replacement. Many
of the `sendSyncMessage` callers don't actually use the result, and can just
be changed to `sendAsyncMessage`. And many of the existing async messaging
users can be changed to just use `sendQuery` rather than sending messages and
adding response listeners.
However, the APZ code is an exception. It relies on intricate properties of
the event loop, and doesn't have an easy way to slot in promise handlers, so I
migrated it to using sync messaging via process message managers instead.
Differential Revision: https://phabricator.services.mozilla.com/D35055
--HG--
extra : rebase_source : d5707e87f293a831a5cf2e0b0a7e977090267f78
extra : source : 75ebd6fce136ab3bd0e591c2b8b2d06d3b5bf923
The SpecialPowers set*Pref/get*Pref APIs currently use synchronous messaging
to set and get preference values from the parent process. Aside from directly
affecting callers of those APIs, it also affects callers of `pushPrefEnv`,
which is meant to be asynchronous, but is in practice usually synchronous due
to the synchronous messaging it uses.
This patch updates the getPref APIs to use the in-process preference service
(which most callers are expecting anyway), and also updates the callers of
the setPref and pushPrefEnv APIs to await the result if they're relying on it
taking effect immediately.
Unfortunately, there are some corner cases in tests that appear to only work
because of the quirks of the current sync messaging approach. The synchronous
setPref APIs, for instance, trigger preference changes in the parent
instantly, but don't update the values in the child until we've returned to
the event loop and had a chance to process the notifications from the parent.
The differnce in timing leads some tests to fail in strange ways, which this
patch works around by just adding timeouts.
There should be follow-ups for test owners to fix the flakiness.
Differential Revision: https://phabricator.services.mozilla.com/D35054
--HG--
extra : rebase_source : 941298157e7c82f420cf50ce057154ce9b85301c
extra : source : 189dc8a359815e059a4a217f788d183260bb2bfe
* calculateNetworkId is now called before sending each ChangeEvent
* mNetworkId is truncated when no IPv4/IPv6 IDs could be computed
Differential Revision: https://phabricator.services.mozilla.com/D35780
--HG--
extra : moz-landing-system : lando
We want dweb URLs to continue working as before bug 1536744 landed.
So we make sure to instantiate it as an nsStandardURL.
This is not a good long-term solution, as we don't want to hardcode
all the various schemes that we want to behave properly.
The fix would be to add a new spec-compliant nsIURI implementation,
based on RustURL and use it for all unknown schemes.
See bug 1561860 for a more complete solution.
Differential Revision: https://phabricator.services.mozilla.com/D36168
--HG--
extra : moz-landing-system : lando
* calculateNetworkId is now called before sending each ChangeEvent
* mNetworkId is truncated when no IPv4/IPv6 IDs could be computed
Differential Revision: https://phabricator.services.mozilla.com/D35780
--HG--
extra : moz-landing-system : lando
Previously we would throw in nsFtpProtocolHandler::NewURI. Since that doesn't exist anymore, and creating FTP URLs always works, we need to make sure creating the FTP channel doesn't work anymore.
Differential Revision: https://phabricator.services.mozilla.com/D35642
--HG--
extra : moz-landing-system : lando
