This replaces the old DOMWindowCreated event, and allows SpecialPowers to still
be instantiated for each new chrome document.
Differential Revision: https://phabricator.services.mozilla.com/D47337
--HG--
extra : moz-landing-system : lando
These still fail or timeout because of missing platform features, but at least
the tests will pass once those platform features are fixed after this.
Differential Revision: https://phabricator.services.mozilla.com/D48221
--HG--
extra : moz-landing-system : lando
This replaces the old DOMWindowCreated event, and allows SpecialPowers to still
be instantiated for each new chrome document.
Differential Revision: https://phabricator.services.mozilla.com/D47337
--HG--
extra : moz-landing-system : lando
Prior to this patch, assertions in SpecialPowers.spawn callbacks only work
when the caller was in a window with a SimpleTest harness.
This patch fixes that by registering a default assertion handler at the start
of a test, and sending assertions from any task without its own harness to
said default handler.
MANUAL PUSH: Contains complex rename operations that I don't trust Lando to
handle correctly.
Differential Revision: https://phabricator.services.mozilla.com/D42210
--HG--
extra : rebase_source : b0b72ce166647621a50aad0af8f130c0d89e3829
extra : source : 41b6d03a870caa7c4be2146ce8c8d84efdb20e79
While working on porting the (audio-playback indicators) bug 1562990 to fission, we saw the potential to delete some methods in nsIDOMWindowUtils because they were not used anymore in our codebase except in a couple of tests files. So now, we should only mute/unmute or change the volume in the parent process. As such, interfaces are added in SpecialPowers to change media muted or volume state from content processes.
Differential Revision: https://phabricator.services.mozilla.com/D41782
--HG--
extra : moz-landing-system : lando
The tests currently rely on being able to create new frames in and new windows
from cross-origin iframes, which clearly won't work under Fission. This patch
changes that logic, but leaves the tests skipped since they also rely on
cross-origin window.postMessage, which doesn't work yet.
Differential Revision: https://phabricator.services.mozilla.com/D41471
--HG--
extra : rebase_source : ab7cf98bcd57d81018feaee46d018c85e3e4bfa3
It does not make sense to copy masked password with mask characters.
Therefore, we should allow users to copy/cut in password fields only when
selected range is in unmasked range.
Note that for web-compat, copy/cut are always enabled in HTML/XHTML document
in content. Therefore this patch changes the behavior only in chrome's
password fields.
Additionally, only the test uses `nsIEditor.canDelete()`. Therefore, this
removes it and make the test use `nsIDocShell.isCommandEnabled()` instead.
Unfortunately, `nsIEditor.canCopy()` and `nsIEditor.canCut()` are used by
BlueGriffon, therefore, we cannot get rid of them for now.
Differential Revision: https://phabricator.services.mozilla.com/D38999
--HG--
rename : editor/libeditor/tests/test_bug1067255.html => editor/libeditor/tests/test_cut_copy_delete_command_enabled.html
extra : moz-landing-system : lando
As originally implemented, nsISiteSecurityService.removeState allowed direct
access to remove HSTS state. It also provided the implementation for when the
browser encountered an HSTS header with "max-age=0". In bug 775370, it was
updated to store an entry that would override preloaded information when
processing such headers. However, this meant that the semantics of the direct
access API had changed. Preloaded information could be overridden if a user
invoked the "forget about this site" feature. This change fixes the public API
(and renames it to "resetState") so it actually behaves as its consumers expect.
Reviewers: jcj!, KevinJacobs!
Tags: #secure-revision
Bug #: 1564481
Differential Revision: https://phabricator.services.mozilla.com/D38108
--HG--
extra : rebase_source : 8dd5460d3fd3c0ce92746cc83fae220d6e2a83cf
extra : amend_source : 171ebb015e9f9ae775f0caa22e161d41970f3d51
With out-of-process iframes, we'll need similar functionality to the
ContentTask helpers that can be used in any process, with any type of frame.
Using ContentTask directly in unprivileged contexts will, I think, be a bit
too combersome given how often it's needed, so this patch adds an API directly
to SpecialPowers instead.
The environment provided to the task is currently pretty basic, and doesn't
provide the assertion helpers currently available to ContentTask tasks, but it
can grow as we find it necessary.
Differential Revision: https://phabricator.services.mozilla.com/D35058
--HG--
extra : rebase_source : baecc56b24c7366d276dad59e7b8f6e087b26ece
extra : source : 8a3d311c7fac75b5902f2fa9dc651137a499fc18
`loadChromeScript` is often called with http: URLs pointing to mochitest
resources, which need to be read synchronously before they can be executed.
Unfortunately, while the API for this pretends to be synchronous, it really
spins the event loop underneath.
When we attempt to use it in the parent, that means that we spin the event
loop and process messages from the child before the script has been executed.
And since those messages often contain messages intended for the chrome
script, that causes problems.
When the chrome script APIs use sync messaging, this doesn't matter much,
since the `loadChromeScript` call blocks the caller until the message handler
in the parent returns. When it uses async messaging, though, we have no such
luck, and the messages intended for the script get sent to the parent
immediately.
Loading the script contents in the child solves this problem, since it
reliably blocks the child callers until the script contents are ready, and
doesn't give them a chance to try to send messages to the script while it's
still being read.
Differential Revision: https://phabricator.services.mozilla.com/D35056
--HG--
extra : rebase_source : 137a244f2c071977ee633631de05f7fd776e9b88
extra : source : c2697f04d38cf0b01b1f3e227910ab5890926a33
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
When we migrate SpecialPowers to a JSWindowActor, it will no longer be able to
use synchronous IPC messaging, which means that its current synchronous APIs
will have to become asynchronous.
This patch doesn't change the behavior of those functions, but it does change
their callers to `await` their return values rather than using them directly.
This pattern will work the same whether the functions return a promise or a
plain value, which simplifies the migration.
Differential Revision: https://phabricator.services.mozilla.com/D35053
--HG--
extra : rebase_source : baffba2107b175250573baae3f54d48becbd2a16
extra : source : b4ed40bea2698802ef562a0931c0b560737fb89d
Christoph Kerschbaumer
Bogdan Tara
Kris Maglione
Neil Deakin
Nika Layzell
Brindusan Cristian
Mike Conley
Abdoulaye O. Ly
Jan Varga
Matt Woodrow
Jared Wein
Simon Giesecke
Masayuki Nakano
Boris Zbarsky
Dana Keeler
Jonathan Kingston
Victor Porof