***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
Automatic changes by ESLint, except for manual corrections for .xml files.
Differential Revision: https://phabricator.services.mozilla.com/D4439
--HG--
extra : moz-landing-system : lando
This adds the basic framework for defining IPC actors which are lazily
instantiated for the appropriate frame loaders based on DOM events, message
manager messages, and observers. Actual actors are defined in follow-up
commits.
MozReview-Commit-ID: Jb6CWWW7v3v
--HG--
extra : rebase_source : 6c465c492ef423616346d70047c4fd4b074af303
In our autoplay shield-study, we want to collect the information which could tell us how many website
contains audible autoplay media, but there is no way to get this information on current API desigin.
Therefore, I would like to send a new notification when autoplay occurred.
The extension code could get the information by following way,
```
Services.obs.addObserver((subject, topic, data) => {
// DO SOMETHING
}, "AudibleAutoplayMediaOccurred");
```
MozReview-Commit-ID: 4bSYcxDZOGK
--HG--
extra : rebase_source : 2a4f060dbd582419bf0727408b04f2540155aa02
Believe it or not, the memory these references hold alive is significant.
Nulling them out saves 5-10K per process.
MozReview-Commit-ID: JONjE48yE8I
--HG--
extra : rebase_source : 49adc538070eecb9183e6e052e6e43db9c4c7a99
extra : histedit_source : 699f49fad1bfa69b8c511bf96187096e751c8606
(This patch was first presented for review in bug 1463919, I've split it off
into its own bug here).
If the user opens a tab in the background, and that tab tries to play media,
we'll delay playing that media until the tab is brought to the foreground.
But the user can explicitly start playback of such delayed media by clicking
the "play" icon we show in the tab indicator. Then if autoplay is disabled,
we'll block the play (unless the origin is whitelisted). This is bad, as the
user has clearly indicated intent to play media in this tab.
So this patch "gesture activates" the root content document when the tab audio
indicator play button is pressed. This means the block autoplay logic will
behave as if there's been a user gesture in the tab (mouse click or keypress),
and not block the play. Gesture activation state is per document, so it does
not persist across document loads.
MozReview-Commit-ID: 3pgrADRrJqt
***
fix
--HG--
extra : rebase_source : a099cd3eedf6785a7af0b95613c5bd210e791a53
(This patch was first presented for review in bug 1463919, I've split it off
into its own bug here).
If the user opens a tab in the background, and that tab tries to play media,
we'll delay playing that media until the tab is brought to the foreground.
But the user can explicitly start playback of such delayed media by clicking
the "play" icon we show in the tab indicator. Then if autoplay is disabled,
we'll block the play (unless the origin is whitelisted). This is bad, as the
user has clearly indicated intent to play media in this tab.
So this patch "gesture activates" the root content document when the tab audio
indicator play button is pressed. This means the block autoplay logic will
behave as if there's been a user gesture in the tab (mouse click or keypress),
and not block the play. Gesture activation state is per document, so it does
not persist across document loads.
MozReview-Commit-ID: 3pgrADRrJqt
***
fix
--HG--
extra : rebase_source : 3290571b61cfed5653cd75c859c8520ef5c8ee2f
Since we're naming this new file as DateTimePickerContent, it's also a good opportunity to rename the DateTimePickerHelper to DateTimePickerParent to make it more meaningful
MozReview-Commit-ID: 9xNwUjZb6UF
--HG--
rename : toolkit/content/browser-content.js => toolkit/modules/DateTimePickerContent.jsm
rename : toolkit/modules/DateTimePickerHelper.jsm => toolkit/modules/DateTimePickerParent.jsm
extra : rebase_source : 89cbaa19e74a904d39087de2cdfbc2789c40057f
This is a partial backout of Bug 1347791 part 3; a5fbb7e2d1d0.
a5fbb7e2d1d0 added a mediaBlocked attribute to the browser element, which
tracked whether the tab has ever been in the foreground, so that this could
be saved and restored in session restore. We don't session restore this
anymore, so we can remove this attribute and associated event handlers.
This also removes the media.autoplay* pref accesses which are accounted for in
the test browser_preferencecs_usage.js, so remove those prefs from that test.
MozReview-Commit-ID: HLeylLzEsW8
--HG--
extra : rebase_source : 3b169c324b4a0c5163151805d9fcdb0b90a37517
This also removes any redundant Ci.nsISupports elements in the interface
lists.
This was done using the following script:
acecb401b7/processors/chromeutils-generateQI.jsm
MozReview-Commit-ID: AIx10P8GpZY
--HG--
extra : rebase_source : a29c07530586dc18ba040f19215475ac20fcfb3b
Mark Banner
Victor Porof
Kris Maglione
Brindusan Cristian
Cosmin Sabou
Andreea Pavel
alwu
Boris Zbarsky
Chris Pearce
Tom Schuster
Felipe Gomes
Gijs Kruitbosch