Skip to content
  • Gijs Kruitbosch's avatar
    Bug 1633790 - allow PDF.js use when we've misled the user into misconfiguring... · 6c3c9b5b
    Gijs Kruitbosch authored
    Bug 1633790 - allow PDF.js use when we've misled the user into misconfiguring PDF handlers, r=jaws,mattwoodrow
    
    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
    6c3c9b5b