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
It turned out that `ShellExecuteByExplorer` does not work on VDI such as Citrix
or Microsoft RemoteApp. This patch adds a fallback to the original launching
code if `ShellExecuteByExplorer` fails. This will be a temporary solution until
we find out a way to solve both interop issues `PreferSystem32Images` and VDI.
Differential Revision: https://phabricator.services.mozilla.com/D58054
--HG--
extra : moz-landing-system : lando
* Makes it possible to selectively enable TRR for pbmode/container/window/etc
Differential Revision: https://phabricator.services.mozilla.com/D48363
--HG--
extra : moz-landing-system : lando
This changeset is a simple find and replace of `MOZ_FALLTHROUGH` and `[[fallthrough]]`.
Unfortunately, the MOZ_FALLTHROUGH_ASSERT macro (to assert on case fallthrough in debug builds) is still necessary after switching from [[clang::fallthrough]] to [[fallthrough]] because:
* MOZ_ASSERT(false) followed by [[fallthrough]] triggers a -Wunreachable-code warning in DEBUG builds
* but MOZ_ASSERT(false) without [[fallthrough]] triggers a -Wimplicit-fallthrough warning in NDEBUG builds.
Differential Revision: https://phabricator.services.mozilla.com/D56440
--HG--
extra : moz-landing-system : lando
A fix for Bug 1588975 replaced the call to `LaunchWithIProcess` in
`nsMIMEInfoWin::LaunchWithFile` with the call to `ShellExecuteWithIFile` to use
`mozilla::ShellExecuteByExplorer`. This caused a regression that if a filepath
contains whitespaces, we pass it to a target application without quoting it
while the old codepath `ShellExecuteWithIFile` quoted a path accordingly in
`assembleCmdLine`.
A proposed fix is to quote a path in the same way as `assembleCmdLine` does.
This patch also moves `assembleCmdLine` to an exported header so that we can add
a unittest to cover both of `assembleCmdLine` and a new function
`assembleSingleArgument. It would be better to refactor these functions in the
future because many lines are duplicated.
Differential Revision: https://phabricator.services.mozilla.com/D56646
--HG--
extra : moz-landing-system : lando
Previously, GetCancelled() would have return true should the channel's status was an error.
Doing Cancel(NS_OK) for example, would have made a follow-up call to GetCancelled() return false. However, we can assert that such a call would have been a bug.
Following this change GetCancelled() will only return true if Cancel() was explicitly called.
Differential Revision: https://phabricator.services.mozilla.com/D55401
--HG--
extra : moz-landing-system : lando
There is no functional change with this commit. The default implementation for GetCanceled() is still to check if the status code is a failure.
However, it can be argued that as you had to call Cancel() on the nsIChannel, having to check the nsIHttpChannelInternal interface to determine if you had been canceled in the past was rather a non obvious path.
It makes more sense to check the nsIChannel interface to determine if it's been canceled already and this allows for finer granularity if needed in the future.
Differential Revision: https://phabricator.services.mozilla.com/D55268
--HG--
extra : moz-landing-system : lando
Previously, GetCancelled() would have return true should the channel's status was an error.
Doing Cancel(NS_OK) for example, would have made a follow-up call to GetCancelled() return false. However, we can assert that such a call would have been a bug.
Following this change GetCancelled() will only return true if Cancel() was explicitly called.
Differential Revision: https://phabricator.services.mozilla.com/D55401
--HG--
extra : moz-landing-system : lando
There is no functional change with this commit. The default implementation for GetCanceled() is still to check if the status code is a failure.
However, it can be argued that as you had to call Cancel() on the nsIChannel, having to check the nsIHttpChannelInternal interface to determine if you had been canceled in the past was rather a non obvious path.
It makes more sense to check the nsIChannel interface to determine if it's been canceled already and this allows for finer granularity if needed in the future.
Differential Revision: https://phabricator.services.mozilla.com/D55268
--HG--
extra : moz-landing-system : lando
The only time we fire OnStart/StopRequest from nsExtProtocolChannel is when we cancel with NS_ERROR_NO_CONTENT, which DocumentLoadListener explicitly handles to avoid calling Suspend (which asserts).
Unfortunately we fire OnStart/StopRequest from a runnable, so it's possible for the channel to get Cancelled by something else in the middle. This Cancel doesn't really work, since we've already dispatched to the handler, so don't update mStatus.
Depends on D57030
Differential Revision: https://phabricator.services.mozilla.com/D57032
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
Most of these fixes involve fixing test XUL to not use <dialog> as a top level element or replacing calls to document.documentElement that expect it to return the dialog, now that the dialog is not the top level element anymore.
Differential Revision: https://phabricator.services.mozilla.com/D53722
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55444
--HG--
extra : moz-landing-system : lando
Sylvestre Ledru
Marco Bonardo
Noemi Erli
Paul Bone
Andreea Pavel
Dorel Luca
Simon Giesecke
shindli
Geoff Lankow
Gijs Kruitbosch
Narcis Beleuzu
Matt Woodrow
Dimi Lee
Brindusan Cristian
Zibi Braniecki
Toshihito Kikuchi
Valentin Gosu
Emma Malysz
Chris Peterson
Jean-Yves Avenard
Kris Maglione
Kirk Steuber
Tom Ritter
Daniel Varga
Gabriele Svelto
Boris Zbarsky