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
Loading SpecialPowers into frame scripts has side-effects, detailed in part 1,
which are undesirable. The main side-effect that I'm trying to get rid of here
is the force-enabling of permissive COWs in frame script scopes, which is
blocking changes that I need to make elsewhere. But both that and the scope
pollution it causes are likely to allow code to work when running in
automation which fails in real world usage.
This patch changes our special powers frame scripts to load specialpowers.js
and specialpowersAPI.js as JSMs, which run in their own global, but define
most of the same properties on our frame script globals.
Most other callers still load those scripts via <script> tags or the subscript
loader, and should ideally migrated in a follow-up. But even so, this patch
still gives us a cleaner separation of the frame script and non-frame-script
loading code.
MozReview-Commit-ID: CR226gCDaGY
--HG--
extra : rebase_source : 251574d238ded31b9df32dc89852251831d55757
extra : source : c53c7b0249ad3359fbc9f144f2cf9ca3b6386c59
Loading SpecialPowers into frame scripts has side-effects, detailed in part 1,
which are undesirable. The main side-effect that I'm trying to get rid of here
is the force-enabling of permissive COWs in frame script scopes, which is
blocking changes that I need to make elsewhere. But both that and the scope
pollution it causes are likely to allow code to work when running in
automation which fails in real world usage.
This patch changes our special powers frame scripts to load specialpowers.js
and specialpowersAPI.js as JSMs, which run in their own global, but define
most of the same properties on our frame script globals.
Most other callers still load those scripts via <script> tags or the subscript
loader, and should ideally migrated in a follow-up. But even so, this patch
still gives us a cleaner separation of the frame script and non-frame-script
loading code.
MozReview-Commit-ID: CR226gCDaGY
--HG--
extra : rebase_source : fa253abde2029ec09c724404106d83623f064875
There was some unused code in this file which was wasting memory.
This patch also avoids some more policies from being sent to the content process as they are not really needed there
MozReview-Commit-ID: C4FzesWMQi0
--HG--
extra : rebase_source : ba21f04cca8614d9dd4b34f4e093ece0e3153502
This is also gone from the parent process because previously it was forced to be early loaded by the fact that process-content.js also runs in the parent. Now the parent side is first initialized by the Cu.import from the Activity Stream code, which is later in the startup process
MozReview-Commit-ID: FEypEi0Eemc
--HG--
extra : rebase_source : 6a682dff38370410c91cac44f1f5b2739f0247d1
This is a quick-and-dirty port. It might be nice to replace
SpecialPowersObserver with the webextensions content script injection
system at some point, but that isn't practical right now (since WE experiments
cannot implement new APIs visible to content scripts).
MozReview-Commit-ID: GinCu3VcbWK
--HG--
rename : testing/specialpowers/bootstrap.js => testing/specialpowers/api.js
extra : rebase_source : 0faf7d21c8868c957ddc7fede0d56809f27dc161
extra : intermediate-source : ffb9ce93b92dd6396bfe038d3f6a8bcf929ec277
extra : source : cca596eadd0437dc75b75c119b6c7a405805f703
This should prevent new files from being added in the startup path for content processes
MozReview-Commit-ID: 6hCLurrVQ67
--HG--
extra : rebase_source : 82d161e536decae07cef04b35e3233e947c5b0e7
The "pageshow" and "blur" event listeners in LoginManagerContent only matter
once the module has loaded and processed other events. Before that, they're
guaranteed to be no-ops.
This patch delays adding those listeners before LoginManagerContent is used
for a given frame script.
MozReview-Commit-ID: 1f5AOkRkAhp
--HG--
extra : source : bab121b4dd84f9715e6a9efa652556a91ea60a3c
The "pageshow" and "blur" event listeners in LoginManagerContent only matter
once the module has loaded and processed other events. Before that, they're
guaranteed to be no-ops.
This patch delays adding those listeners before LoginManagerContent is used
for a given frame script.
MozReview-Commit-ID: 1f5AOkRkAhp
--HG--
extra : rebase_source : 392abe8ca2743fa4fdc40e642743acef1b314683
This inlines and simplifies the call to XPCOMUtils._getFactory,
because otherwise passing PdfStreamConverter appears to resolve it
immediately, loading the JSM. (The stream converter prototype does not
have a property _xpcom_factory, so there's no need for the check.)
Once that is done, we can just lazily load the stream converter JSM to
keep it from being loaded on startup.
This patch also checks that the stream converter is not loaded at
startup in the main process or the content process, and that PdfJs.jsm
is not loaded at startup in the content process. It needs to be loaded
in the main process to watch for some prefs.
MozReview-Commit-ID: EA0pSgs4AWH
--HG--
extra : rebase_source : ebc99d6dc5c00cd45192ec0580f887d8970d9dd0
This inlines and simplifies the call to XPCOMUtils._getFactory,
because otherwise passing PdfStreamConverter appears to resolve it
immediately, loading the JSM. (The stream converter prototype does not
have a property _xpcom_factory, so there's no need for the check.)
Once that is done, we can just lazily load the stream converter JSM to
keep it from being loaded on startup.
This patch also checks that the stream converter is not loaded at
startup in the main process or the content process, and that PdfJs.jsm
is not loaded at startup in the content process. It needs to be loaded
in the main process to watch for some prefs.
MozReview-Commit-ID: EA0pSgs4AWH
--HG--
extra : rebase_source : fd79cf660e55a3b4e033b3f112228f36942169ea
console.assert keeps the same semantics as NS_ASSERT in that it doesn't throw an exception,
but a lot of the places code was using it in a way that would be better served by throwing
an exception when the condition is false.
MozReview-Commit-ID: DEF5HSfYO36
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <