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
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
If a system uses a custom shell instead of Windows Explorer,
`ShellExecuteByExplorer` always fails because it relies on explorer.exe,
but `ShellExecute` stil works because it's in-proc implementation.
We added a fallback for a local file to address Bug 1602726. This patch adds
a fallback for a uri.
Differential Revision: https://phabricator.services.mozilla.com/D63095
--HG--
extra : moz-landing-system : lando
This also fixes the Window lookup in nsExternalAppHandler, which was the reason for previously needing the process-top BrowsingContext.
Differential Revision: https://phabricator.services.mozilla.com/D64910
--HG--
extra : moz-landing-system : lando
Thunderbird has no default handlers so test_check_defaults_get_added does
nothing and test_check_default_modification fails looking for a mailto handler.
Differential Revision: https://phabricator.services.mozilla.com/D62525
--HG--
extra : moz-landing-system : lando
The getDefaultFileName helper function does its own filename parsing using header info
it has previously 'manually' retrieved, so it needs to manually unescape its input.
Meanwhile, NS_GetFilenameFromDisposition is used by webbrowserpersist and for
the title of documents, and so updating that helps ensure better UI as well as
correct filename suggestions when saving from the context menu.
Differential Revision: https://phabricator.services.mozilla.com/D61734
--HG--
rename : accessible/tests/mochitest/moz.png => uriloader/exthandler/tests/mochitest/file_with@@funny_name.png
rename : toolkit/components/mediasniffer/test/unit/data/file.webm => uriloader/exthandler/tests/mochitest/file_with[funny_name.webm
extra : moz-landing-system : lando
The following methods are removed:
1. notifyChannelClassifierProtectionDisabled
2. notifyCookieAllowed
3. notifyCookieBlocked
Depends on D56875
Differential Revision: https://phabricator.services.mozilla.com/D57630
--HG--
extra : moz-landing-system : lando
The following methods are removed:
1. notifyChannelClassifierProtectionDisabled
2. notifyCookieAllowed
3. notifyCookieBlocked
Depends on D56875
Differential Revision: https://phabricator.services.mozilla.com/D57630
--HG--
extra : moz-landing-system : lando
We currently fail to offer 'open with' options for application/zip mimetype
.zip files, because out of the box, the Windows registry does not contain
mimetype entries for application/zip. In fact, it contains comparatively
few entries, and right now we bail out with an empty mime info object if
we cannot find the server-provided mimetype in the registry (or cannot
find an associated extension for that mimetype).
Prior to the changes from bug 1597985, we would first try to find a handler
based on the default extension for the mimetype, and used the file extension
if that failed.
The changes in this commit will cause us to fetch the default file extension
for the mimetype, but continue with the provided extension if no mimetype
information is available, restoring functionality in the case where Windows
has no mimetype information.
Differential Revision: https://phabricator.services.mozilla.com/D60139
--HG--
extra : moz-landing-system : lando
Emilio Cobos Álvarez
Cosmin Sabou
Eric Rahm
Kagami Sascha Rosylight
Bogdan Tara
Christoph Kerschbaumer
Paul Bone
sonakshi
Razvan Maries
Toshihito Kikuchi
Andrea Marchesini
Masatoshi Kimura
Coroiu Cristina
Marco Bonardo
Mark Banner
Matt Woodrow
Dylan Roeh
Sylvestre Ledru
Noemi Erli
Andreea Pavel
Dorel Luca
Simon Giesecke
shindli
Geoff Lankow
Gijs Kruitbosch
Narcis Beleuzu
Dimi Lee
Brindusan Cristian
Zibi Braniecki