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
This is an initial implementation of this idea that works on mac.
I've added a Windows implementation in another commit in this stack. I'll
look at a Linux one in a follow-up bug. I do not think we need them in the
child process implementation or on Android.
Effectively, this makes nsIHandlerInfo::LaunchWithURI() fall back to asking if
the handler info points to the OS default and that's us, or if it points to
a helper app and that's us. The latter is fairly easy to check, but the former,
more common case, is actually annoying - there don't seem to be APIs on the
external helper app service or the handler service that provide any information
about the app that's currently the default. So despite my belief that these
interfaces have too many methods that all do very similar things, and what we
need is fewer interfaces with fewer methods, I added another one...
For this mac implementation, I'm comparing bundle URLs and added newer API
usage for 10.10 and later to avoid deprecation warnings. I've not changed
the mac shell service as it uses bundle identifiers to check if we're the
default.
Another way of fixing these issues would be to complain about things when we
receive these URIs from external parties and our own config says that we will
just hand them to someone else. I decided not to do so because we end up with
at least one of the following problems:
- if we implement in BrowserContentHandler, that won't help for
PWAs/Thunderbird
- if we try to implement in the external protocol handler, we'd need to start
passing load flag information through to lots of checks.
- it wouldn't stop the recursion until we've already done one round of
it for links that are in webpages, which seems suboptimal (ie, if you
clicked a mailto: link on a webpage it'd go to the OS with that mailto link
and only realize something's awry when we've gone back through the OS to us,
rather than straightaway).
If we wanted to, we could add a fix like that in belt-and-suspenders fashion.
Differential Revision: https://phabricator.services.mozilla.com/D48742
--HG--
extra : moz-landing-system : lando
The patch for Bug 1588975 specified the "open" verb to execute a target, but
the default verb is not always "open". For example, the default verb for a font
file is "preview". We should specify null verb to start the default operation.
Now we use `IShellDispatch2.ShellExecute` to ask explorer.exe to call
`ShellExecuteExW`. That method takes an optional `VARIANT` parameter as a verb.
According to https://devblogs.microsoft.com/oldnewthing/20140919-00/?p=44023,
we need to pass `VT_ERROR` to omit an optional parameter. If we pass
other values such as `nullptr` with `VT_BSTR` or `VT_EMPTY`, explorer.exe calls
`ShellExecuteExW` with the empty string `""` instead of `nullptr`, which is not
considered as a valid verb if the target file is not associated with any app.
Differential Revision: https://phabricator.services.mozilla.com/D54036
--HG--
extra : moz-landing-system : lando
The signatureInfo that has been used in ExternalHelperAppService and
ReputationService has been stored Array of nsIX509CertList, which
isn't necessary because only the raw bytes of the certs are required.
This patch intends to remove the usage of nsIX509CertList and store
the raw bytes directly.
Differential Revision: https://phabricator.services.mozilla.com/D44243
--HG--
extra : moz-landing-system : lando
The launcher process turns on the `PreferSystem32Images` mitigation policy for
the browser process. Since the mitigation policy is inherited, a process launched
by the browser process also has `PreferSystem32Images`. If an application which
does not support `PreferSystem32Images`, such as Skype for Business, is launched
via a hyperlink, a custom uri, or a downloaded file, it would fail to launch.
Bug 1567614 fixed this issue by introducing `mozilla::ShellExecuteByExplorer` to
`nsMIMEInfoWin::LoadUriInternal`. This patch introduces
`mozilla::ShellExecuteByExplorer` to two more places.
1. xul!nsLocalFile::Launch
This is invoked when a user opens a file from the Download Library, or a user
opens a downloaded file with the default application without saving it.
2. xul!nsMIMEInfoWin::LaunchWithFile
This is invoked when a user opens a downloaded file with a custom application
(configured in about:preference) without saving it.
*Why does this patch change worker.js?*
The mochitest dom/tests/browser/browser_test_new_window_from_content.js failed
if it was executed after dom/serviceworkers/test/browser_download.js in the
same batch. This was because browser_download.js launched Notepad to open
fake_download.bin.txt, preventing a new window from being opened in the
foreground in browser_test_new_window_from_content.js.
The test browser_download.js can verify downloaded data without opening an
associated application. So this patch adds the content-type to the response
header in order not to open Notepad on Windows.
Differential Revision: https://phabricator.services.mozilla.com/D52567
--HG--
extra : moz-landing-system : lando
This also converts MaybeCloseWindowHelper, and results in the window close operations being always run in the parent (even without DocumentChannel).
Differential Revision: https://phabricator.services.mozilla.com/D49528
--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
* 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
* 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
