This patch will
- remove `MediaControlKeysEvent` and use `MediaControlKey` to replace it
- rename names for all `MediaControlKey` related methods, functions, classes and descriptions
The advantage of doing so are
- remove the duplicated type so that we only need to maintain `MediaControlKey`
Differential Revision: https://phabricator.services.mozilla.com/D78140
This is mostly changes to handle retrieving the security state asynchronously via the parent process, needing lots of async/await additions.
It also removes the docshell mixed content flag checks (which don't seem to be used in code, only tests), which are mostly still covered by checks of the security UI.
Differential Revision: https://phabricator.services.mozilla.com/D75448
This is mostly changes to handle retrieving the security state asynchronously via the parent process, needing lots of async/await additions.
It also removes the docshell mixed content flag checks (which don't seem to be used in code, only tests), which are mostly still covered by checks of the security UI.
Differential Revision: https://phabricator.services.mozilla.com/D75448
This value is determined in Parent process and passed down to nsDocShell. Delete
the messages to pass the setting down and set it on the BrowsingContext in the
Parent process.
Refactor the code that determines to opt-out of using global history. Code
inspection determines that windowless browsing contexts want to opt-out as well
as any frame with `disableglobalhistory` attribute set on it.
Differential Revision: https://phabricator.services.mozilla.com/D72279
Raw Cr.ERROR don't get stack information, same as throwing JS literals instead
of `new Error()`s.
This was done automatically with a new eslint rule that will be introduced in
the next commit. One instance of a raw Cr.ERROR was not replaced since it is
used in a test that specifically checks the preservation of raw Cr values in
XPCJS. The rule will be disabled for that instance.
Differential Revision: https://phabricator.services.mozilla.com/D28073
We need it to live in BrowsingContext instead of WindowContext, because
we need to preserve the zoom level across same-origin navigation.
It'd be nice if it only lived in the top BC, but that's not possible at
the moment because a lot of tests rely on zooming only iframes. Some of
them can be adjusted for scaling the top instead, but not sure it's
worth it's worth fixing them and moving the zoom to be top-only, as it'd
be a bunch of effort, and the complexity and overhead of propagating the
zoom is not so big.
The print-preview-specific code in nsContentViewer is from before we did
the document cloning setup, and it seems useless. I've tested print
preview scaling before and after my patch and both behave the same.
The rest is just various test changes to use the SpecialPowers APIs or
BrowsingContext as needed instead of directly poking at the content
viewer.
I named the pres context hook RecomputeBrowsingContextDependentData, as
more stuff should move there like overrideDPPX and other media emulation
shenanigans.
I also have some ideas to simplify or even remove ZoomChild and such,
but that's followup work.
Differential Revision: https://phabricator.services.mozilla.com/D71969
Persistent listeners for onMessage and onConnect are special because they
don't have parent EventManagers, so we have a lot of custom code just to keep
track of which extensions have registered them during previous runs.
In this patch, I simplify all that logic to always assume that any extension
which sends messages from content scripts has those listeners setup properly.
The only observable difference is that some poorly written extensions which
were previously broken by delayed startup will now "work" by being started
earlier if a message from a content script arrives during browser startup.
Additionally, unconfuse two different meanings of the "startup" event.
Bonus, avoid some logspam during tests.
Differential Revision: https://phabricator.services.mozilla.com/D70955
These tests used <iframe mozbrowser> for convenience, mostly forcing
themselves to only run in non-e10s mode in the process, but none of them
really have any need to.
Differential Revision: https://phabricator.services.mozilla.com/D70745
These tests used <iframe mozbrowser> for convenience, mostly forcing
themselves to only run in non-e10s mode in the process, but none of them
really have any need to.
Differential Revision: https://phabricator.services.mozilla.com/D70745
These tests used <iframe mozbrowser> for convenience, mostly forcing
themselves to only run in non-e10s mode in the process, but none of them
really have any need to.
Differential Revision: https://phabricator.services.mozilla.com/D70745
I made some changes in preparation for removing nsIScriptError.flags in favor
of nsIConsoleMessage.logLevel.
Differential Revision: https://phabricator.services.mozilla.com/D66878
--HG--
extra : moz-landing-system : lando
I am not sure if you are okay with reviewing all those test changes.
Sadly it's not that easy to search through our huge JavaScript code
base for some generic name like 'isStrict'.
Differential Revision: https://phabricator.services.mozilla.com/D66573
--HG--
extra : moz-landing-system : lando
Before this patch, the TabDelegate was "special" as in it had just one global
delegate that receives events for all extensions and sessions. This was done to
allow mochitests to call tabs.create and tabs.remove.
This hack is no longer needed as now we can notify the embedding layer that a
new extension has been installed and we have a way to list currently installed
extensions.
This patch makes TabDelegate behave the same as the other delegates
(ActionDelegate and MessageDelegate) and will allow further simplications of
the WebExtension Delegate code.
Differential Revision: https://phabricator.services.mozilla.com/D64799
--HG--
extra : moz-landing-system : lando
Before this patch, the TabDelegate was "special" as in it had just one global
delegate that receives events for all extensions and sessions. This was done to
allow mochitests to call tabs.create and tabs.remove.
This hack is no longer needed as now we can notify the embedding layer that a
new extension has been installed and we have a way to list currently installed
extensions.
This patch makes TabDelegate behave the same as the other delegates
(ActionDelegate and MessageDelegate) and will allow further simplications of
the WebExtension Delegate code.
Differential Revision: https://phabricator.services.mozilla.com/D64799
--HG--
extra : moz-landing-system : lando
It allows us to simulate media control key events in non-privileged context, such as a mochitest running in content process.
Differential Revision: https://phabricator.services.mozilla.com/D60783
--HG--
extra : moz-landing-system : lando
Using window.setTimeout is causing a Thunderbird test to stall for not entirely clear reasons. Use dispatchToMainThread instead.
Differential Revision: https://phabricator.services.mozilla.com/D59276
--HG--
extra : moz-landing-system : lando
This patch adds a lot of `beforeinput` event tests into existing mochitests
which test `input` events. But this does not add tests of canceling
`beforeinput` event because it requires really complicated path until
implementing `beforeinput` actually.
Note that `beforeinput` event is not fired with `Document.execCommand()`.
Therefore, this patch does not add WPT for testing `beforeinput` event.
And unfortunately, WPT cannot test most cases of the new tests.
Differential Revision: https://phabricator.services.mozilla.com/D58123
--HG--
extra : moz-landing-system : lando
This patch adds a lot of `beforeinput` event tests into existing mochitests
which test `input` events. But this does not add tests of canceling
`beforeinput` event because it requires really complicated path until
implementing `beforeinput` actually.
Note that `beforeinput` event is not fired with `Document.execCommand()`.
Therefore, this patch does not add WPT for testing `beforeinput` event.
And unfortunately, WPT cannot test most cases of the new tests.
Differential Revision: https://phabricator.services.mozilla.com/D58123
--HG--
extra : moz-landing-system : lando
This patch updates the existing ContentTask.spawn rule to do similar things
for SpecialPowers.spawn calls, only with a slightly different set of globals.
Differential Revision: https://phabricator.services.mozilla.com/D53739
--HG--
extra : moz-landing-system : lando
A number of additional globals are available to ContentTask.spawn tasks
compared to SpecialPowers.spawn tasks. Most of these are available by
accident, as a side-effect of running in a shared frame script global, or
being evaled in the context of the content-task.js frame script, but several
of them are pretty broadly useful, or difficult to obtain from a Sandbox
environment without reaching into arbitrary nearby globals.
This patch adds some of the more useful ones to the default task environment.
Differential Revision: https://phabricator.services.mozilla.com/D53736
--HG--
extra : moz-landing-system : lando
Some tests currently use an initial `ContentTask.spawn` call to import certain
modules into the frame script global that subsequent tasks will run in. Since
each `SpecialPowers.spawn` task runs in its own sandbox, this method doesn't
work for them.
This patch adds a helper, `SpecialPowers.addTaskImport`, which allows similar
functionality by automatically importing the given module for any task spawned
by the `SpecialPowers` instance it was called on.
Differential Revision: https://phabricator.services.mozilla.com/D53735
--HG--
extra : moz-landing-system : lando
ContentTask.spawn supports some common global mochitest assertion methods as
aliases for corresponding Assert methods, along with espected-fail `todo`
variants, and the `info` method for logging messages without triggering
assertions. The easiest way to mass-convert existing callers is to just add
support for these to SpecialPowers.spawn, which this patch does.
Differential Revision: https://phabricator.services.mozilla.com/D53734
--HG--
extra : moz-landing-system : lando
This patch updates the existing ContentTask.spawn rule to do similar things
for SpecialPowers.spawn calls, only with a slightly different set of globals.
Differential Revision: https://phabricator.services.mozilla.com/D53739
--HG--
extra : moz-landing-system : lando
A number of additional globals are available to ContentTask.spawn tasks
compared to SpecialPowers.spawn tasks. Most of these are available by
accident, as a side-effect of running in a shared frame script global, or
being evaled in the context of the content-task.js frame script, but several
of them are pretty broadly useful, or difficult to obtain from a Sandbox
environment without reaching into arbitrary nearby globals.
This patch adds some of the more useful ones to the default task environment.
Differential Revision: https://phabricator.services.mozilla.com/D53736
--HG--
extra : moz-landing-system : lando
Kris Maglione
alwu
Razvan Maries
Masatoshi Kimura
Matt Woodrow
Bogdan Tara
Mihai Alexandru Michis
Dan Glastonbury
Florian Quèze
Ian Moody
Emilio Cobos Álvarez
Tomislav Jovanovic
Ciure Andrei
Tom Schuster
Ed Lee
Agi Sferro
shindli
Cosmin Sabou
Geoff Lankow
Masayuki Nakano
Daniel Varga