зеркало из https://github.com/mozilla/gecko-dev.git
6c3c9b5bf3
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 |
||
|---|---|---|
| .. | ||
| base | ||
| docs | ||
| exthandler | ||
| prefetch | ||
| moz.build | ||