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
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
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
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
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
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
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
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 {, <
