Prior to this patch, PDF.js tracks both its own 'disabled' pref (which is used
by enterprise policy) and whether it is the default handler per the handler
service - but it tracks both in one bool, which determines whether its
streamconverter registers.
Really, what we want is to never use PDF.js if it's preffed off.
However, if there is some other default, it should be acceptable to use PDF.js
in some circumstances, like for <embed> or <object>s where otherwise we
would show no content at all.
Even for toplevel PDFs, if the user has configured Firefox to open PDFs in
an external helper app which is Firefox (which is currently an easy mistake
to make in the unknownContentType dialog), or has it set to the OS default,
but has changed their OS default to Firefox, we really still want to open
those PDFs with PDF.js.
This patch fixes all of this by splitting out the pref tracking from the
handler state tracking. Only the pref will completely disable PDF.js.
Then, in the streamconverter code, we check whether PDF.js should be used for
PDFs, and if there's a misconfiguration that we can correct. This code is
invoked from the parent process when we load PDFs in frames or toplevel
documents, and will prevent us from invoking PDF.js in the child if the user
would prefer that not to happen.
As a driveby, this cleans up how we track the pref inside PDF.js, and how we
get notified of changes to the handler - we were missing changes made in the
unknown content type dialog, so it seemed worth making it generic.
Differential Revision: https://phabricator.services.mozilla.com/D73510
Raw Cr.ERROR don't get stack information, same as throwing JS literals instead
of `new Error()`s.
This was done automatically with a new eslint rule that will be introduced in
the next commit. One instance of a raw Cr.ERROR was not replaced since it is
used in a test that specifically checks the preservation of raw Cr values in
XPCJS. The rule will be disabled for that instance.
Differential Revision: https://phabricator.services.mozilla.com/D28073
I'm taking the opportunity to remove isDefaultHandlerApp messaging as the
content-side calls were removed in bug 1353029.
Depends on D59788
Differential Revision: https://phabricator.services.mozilla.com/D59789
--HG--
extra : moz-landing-system : lando
I'm taking the opportunity to remove isDefaultHandlerApp messaging as the
content-side calls were removed in bug 1353029.
Depends on D59788
Differential Revision: https://phabricator.services.mozilla.com/D59789
--HG--
extra : moz-landing-system : lando
SpecialPowers.spawn bounces tasks off SpecialPowersParent before sending them
to SpecialPowersChild, which means that any operations which are sent
immediately afterwards and take a more direct route (like zoom changes) will
get to the content process before the task starts running. In the case of
tasks which depending on registering a listener before said operations take
place, this is obviously a problem.
So this patch fixes those cases in this test to wait for the listeners to be
setup before continuing.
Differential Revision: https://phabricator.services.mozilla.com/D57870
--HG--
extra : moz-landing-system : lando
We don't want to run stream conversion in the parent (since a lot of them require access to the document), so this instead adds a way to find out what their output type will be.
Differential Revision: https://phabricator.services.mozilla.com/D56134
--HG--
extra : moz-landing-system : lando
We don't want to run stream conversion in the parent (since a lot of them require access to the document), so this instead adds a way to find out what their output type will be.
Differential Revision: https://phabricator.services.mozilla.com/D56134
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando