There was an error trying to redefine variables from l10n.js via loadSubScript. We really only need
it loaded once like a frame script but I had to fix the l10n.js code to handle this properly.
MozReview-Commit-ID: EbNrEaRQJbs
--HG--
extra : rebase_source : 6e544dd61798ebe3865ca108e59392a1319d7eeb
Have the home preferences page notify when it loads instead of relying on findInPage to trigger sync pane to init.
MozReview-Commit-ID: EJlJDfYBHFO
--HG--
extra : rebase_source : ae5104ec18aefca9241be1b61072b786fa9e6815
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
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 : d871033c17a0c42a41b62ad753f4d6221f2118a8
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 : 9c89c3959981df76f7f6c6e4d0a2cf89d7bfb777
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 : f4819b4ae9a406c95aa7fd6a757b0331c9963946
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
By showing users an upsell, positioned as a feature, as part of the save confirmation and make it easy for users to get the mobile app, more users will understand the value of the Pocket mobile and start using the mobile app.
The initial experiment will target existing logged in English users only.
We've added flags to the server response on the save request that:
- Set whether the user has the mobile app
- Which variant of the experiment the user should be enrolled in
If the user has an account, but they've never installed the Android or iOS app, we will display a new button inline in the current panel that will email a link to the mobile application to the user.
MozReview-Commit-ID: 2xtPv5GPVbL
***
Bug 1451840 - Add button to Pocket doorhanger to request mobile app
- Specified default color on buttons
- Removed unnecessary css styles
- Resized icon display size
- Made RTL friendly
- Simplified SVGs
- Updated buttons to be html buttons for screen readers
MozReview-Commit-ID: HdTi1CZbXdc
--HG--
extra : rebase_source : ac259ac308d7a08dcbddb43b9420f7f997f57e23
By showing users an upsell, positioned as a feature, as part of the save confirmation and make it easy for users to get the mobile app, more users will understand the value of the Pocket mobile and start using the mobile app.
The initial experiment will target existing logged in English users only.
We've added flags to the server response on the save request that:
- Set whether the user has the mobile app
- Which variant of the experiment the user should be enrolled in
If the user has an account, but they've never installed the Android or iOS app, we will display a new button inline in the current panel that will email a link to the mobile application to the user.
MozReview-Commit-ID: 2xtPv5GPVbL
***
Bug 1451840 - Add button to Pocket doorhanger to request mobile app
- Specified default color on buttons
- Removed unnecessary css styles
- Resized icon display size
- Made RTL friendly
- Simplified SVGs
- Updated buttons to be html buttons for screen readers
MozReview-Commit-ID: HdTi1CZbXdc
--HG--
extra : rebase_source : e26cac9dc9cd8cc6cfc5c86a768eec9505594812
