1. 17 Mar, 2021 10 commits
  2. 04 Jun, 2020 1 commit
  3. 01 Jun, 2020 1 commit
  4. 29 May, 2020 1 commit
  5. 06 May, 2020 1 commit
  6. 29 May, 2020 1 commit
  7. 20 May, 2020 1 commit
  8. 19 May, 2020 1 commit
  9. 18 May, 2020 1 commit
  10. 15 May, 2020 3 commits
  11. 14 May, 2020 3 commits
  12. 13 May, 2020 2 commits
  13. 12 May, 2020 2 commits
  14. 06 May, 2020 3 commits
    • Liang-Heng Chen's avatar
    • 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
    • Gijs Kruitbosch's avatar
      Bug 1633365 - stop loading page style actors except in tabbrowser browsers, r=florian · b63c2a54
      Gijs Kruitbosch authored
      I filed a bug for the generic version of this as bug 1635131, but we can
      stop the immediate problem here by just not running this actor except
      for tabbrowser browsing contexts.
      
      Differential Revision: https://phabricator.services.mozilla.com/D73715
      b63c2a54
  15. 05 May, 2020 2 commits
  16. 01 May, 2020 1 commit
  17. 29 Apr, 2020 1 commit
  18. 30 Apr, 2020 2 commits
  19. 29 Apr, 2020 2 commits
  20. 27 Apr, 2020 1 commit