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 makes it much easier to update existing consumers of
XPCOMUtils.enumerateCategoryEntries to use the category manager directly.
It also, unfortunately, requires updating existing category manager consumers
to use the Services getter in order to avoid ESLint errors.
Differential Revision: https://phabricator.services.mozilla.com/D4278
--HG--
extra : rebase_source : fb9fd9b21db80af472ff6250a2e9a35e8d538147
I generally tried to preserve the behavior of consumers where they treated an
exception from getInterface(Ci.nsIContentFrameMessageManager) as a signal to use
some sort of fallback.
I did change the behavior of consumers that walked up to the root same-type
docshell before getting the message manager to just get it directly from the
docshell they have. Please review those parts carefully, and let me know if you
want me to ask some subject area experts to review those.
I generally tried to preserve the behavior of consumers where they treated an
exception from getInterface(Ci.nsIContentFrameMessageManager) as a signal to use
some sort of fallback.
I did change the behavior of consumers that walked up to the root same-type
docshell before getting the message manager to just get it directly from the
docshell they have. Please review those parts carefully, and let me know if you
want me to ask some subject area experts to review those.
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
As with the last patch, the factory is only used for a single class,
so move the constants closer to where they are used. This will allow
us to register the stream converter without loading the stream
converter JSM.
MozReview-Commit-ID: DRKVtYQOs2J
--HG--
extra : rebase_source : 09b84838ee31e18db1c70d75d091d3c9f6d95297
Factory is only ever passed PdfStreamConverter, so specialize the
registration method and rename the class. Also, classID2 is always
non-null for PdfStreamConverter, so drop the check.
MozReview-Commit-ID: Ts295QTmrm
--HG--
extra : rebase_source : 0a944fec22df5fb243fbfa65aa4eba91a63e2793
This patch fixes an intermittent failure in the pdf.js browser chrome
Mochitests, where it runs code inside PdfStreamConverter.jsm and gets
the error "TypeError: getBoolPref is not a function". getBoolPref is a
top-level function inside the JSM.
I couldn't reproduce this, but I suspect that defineModuleGetter would
run, and give us a reference to the PdfStreamConverter converter
object in the JSM. Eventually, we would unload this JSM, and somehow
clear out the top level scope. However, the registration JSM still had
its reference to the Converter object. Eventually we would try to
convert again, using the old JSM, but the scope was cleared out, so it
couldn't find the top level function in the converter JSM.
While I could probably work around this somehow by clearing the global
reference to the old JSM and setting up a new thunk, I think it is
better to simply not do the unload. Unloading a JSM is a weird
operation that we don't use much, and I think the only drawback for
not doing so is that a user that disables PDF.js will continue using a
little more memory during that session.
MozReview-Commit-ID: Lx3QZza5qCM
--HG--
extra : rebase_source : cbcf5bc285fa91b5631d388f7ac45fbabaccd34a
The goal of these patches is to load neither PdfJs.jsm nor
PdfStreamConverter.jsm in a content process unless the user is viewing
a PDF, to save memory.
This first patch creates a small stub JSM to do the stream
registration, and calls it directly in the content process, avoiding
one way we load PdfJs.jsm. The existing registration methods are kept
for the main process.
MozReview-Commit-ID: 5GH8tjHXfLb
--HG--
extra : rebase_source : f89b184bf96f2a55c1ee688538f2d5965ffdc660
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
These issues were previously ignored due to the nature of our global import
rules. They need to be fixed before that rule can be updated.
MozReview-Commit-ID: DCChktTc5TW
--HG--
extra : rebase_source : cffb1c9762191c579d1397c8169e6e7635d229da
extra : histedit_source : dea59ddd2daaae52069c5faceae9149a4f08dd73
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 {, <