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
This also renames `saveToDisk` to the more accurate `promptForSaveDestination`
given that it doesn't actually do the saving itself.
Differential Revision: https://phabricator.services.mozilla.com/D73507
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
There are many limitations currently, but this prototype should successfully
render most basic AVIF images. Known limitations:
- No support for any derived image items (crop, rotate, etc.)
- No support for alpha planes
- No support for ICC profiles (bug 1634741)
- The primary image item must be an av01 (no grid support)
- HDR images aren't tone-mapped
Differential Revision: https://phabricator.services.mozilla.com/D68498
There are many limitations currently, but this prototype should successfully
render most basic AVIF images. Known limitations:
- No support for any derived image items (crop, rotate, etc.)
- No support for alpha planes
- The primary image item must be an av01 (no grid support)
- HDR images aren't tone-mapped
Differential Revision: https://phabricator.services.mozilla.com/D68498
There are many limitations currently, but this prototype should successfully
render most basic AVIF images. Known limitations:
- No support for any derived image items (crop, rotate, etc.)
- No support for alpha planes
- The primary image item must be an av01 (no grid support)
- HDR images aren't tone-mapped
Differential Revision: https://phabricator.services.mozilla.com/D68498
Also move MOZ_MUST_USE before function declarations' specifiers and return type. While clang and gcc's __attribute__((warn_unused_result)) can appear before, between, or after function specifiers and return types, the [[nodiscard]] attribute must precede the function specifiers.
I also needed to wrap the nsDocLoader::RemoveChildLoader() function declaration with // clang-format off and // clang-format on. clang-format insists on indenting the function declaration because it is confused by the NS_DECL_ macros without trailing semicolons before the [[nodiscard]] attribute.
Differential Revision: https://phabricator.services.mozilla.com/D70478
--HG--
extra : moz-landing-system : lando
Mostly a matter of:
rg -l '\->LoadingPrincipal' | xargs sed -i 's/->LoadingPrincipal/->GetLoadingPrincipal/g'
And then clang-format. But I tweaked manually nsHttpChannelAuthProvider (move
the variable where it's used, don't take a useless strong ref),
AddonContentPolicy (move the declaration of the variable to the if condition),
and BackgroundUtils (same).
Differential Revision: https://phabricator.services.mozilla.com/D69828
--HG--
extra : moz-landing-system : lando
Mostly a matter of:
rg -l '\->LoadingPrincipal' | xargs sed -i 's/->LoadingPrincipal/->GetLoadingPrincipal/g'
And then clang-format. But I tweaked manually nsHttpChannelAuthProvider (move
the variable where it's used, don't take a useless strong ref),
AddonContentPolicy (move the declaration of the variable to the if condition),
and BackgroundUtils (same).
Differential Revision: https://phabricator.services.mozilla.com/D69828
--HG--
extra : moz-landing-system : lando
This fixes 1597154 because the lists of URIs here and in nsDocShell now
match.
Note that they don't exactly match, there's an exception for about:newtab
which we'll fix in a follow-up bug.
Differential Revision: https://phabricator.services.mozilla.com/D69136
--HG--
extra : moz-landing-system : lando
It's only used to check whether the docshell is gone already, and we need to
deal with that in other places anyway. No other useful implementation.
In comm-central there are a couple, but they're useless too.
Differential Revision: https://phabricator.services.mozilla.com/D68731
--HG--
extra : moz-landing-system : lando
We use `ShellExecuteByExplorer` to open a uri because applications may not
support the mitigation policies inherited from our process.
Unlike Firefox, Thunderbird runs `ShellExecuteByExplorer` to launch a browser
to open an HTTP/HTTPS uri. If a uri includes credentials like
http://user:password@domain.com/, `ShellExecuteByExplorer` succceds, but
explorer.exe refuses to open the uri by design. In this case the fallback to
`ShellExecuteExW` does not happen because the API is async and no error is
returned
The proposed fix is to skip `ShellExecuteByExplorer` if it's Thunderbird.
Because Thunderbird does not apply additional mitigation policies which may
cause compat issues, we don't need to run `ShellExecuteByExplorer` in the
first place.
Differential Revision: https://phabricator.services.mozilla.com/D67339
--HG--
extra : moz-landing-system : lando
Only 3 callers are using a non-UTF-8 charset as the first parameter.
* MediaDocument.cpp: This does not make sense because the "filename" part of
URLs will always be encoded with UTF-8.
* nsContextMenu.js: This is wrong because "mailto:" URLs don't care about the
document charset.
* Finder.jsm: This caused bug 1623222.
Differential Revision: https://phabricator.services.mozilla.com/D67386
--HG--
extra : moz-landing-system : lando
Note that this also suppresses notifications from the initial about:blank in the new process, and updates the tabbrowser to not expect those.
Differential Revision: https://phabricator.services.mozilla.com/D65923
--HG--
extra : moz-landing-system : lando
Honza Bambas
Gijs Kruitbosch
Ian Moody
Jon Bauman
Simon Giesecke
Razvan Maries
Bogdan Tara
sagudev
Jean-Yves Avenard
Matt Woodrow
Cosmin Sabou
Noemi Erli
Sebastian Streich
Kagami Sascha Rosylight
Chris Peterson
Dylan Roeh
Emilio Cobos Álvarez
Eric Rahm
Christoph Kerschbaumer
Paul Bone
sonakshi
Mihai Alexandru Michis
Toshihito Kikuchi
Andrea Marchesini
Masatoshi Kimura
Coroiu Cristina