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
Add a new nsExternalHelperAppService derived class named nsOSHelperAppServiceChild to be used for the MIME service, external helper app service, and external protocol service interfaces in child processes. nsOSHelperAppServiceChild overrides some methods used to get MIME and external protocol handler information from the OS and implements these methods by remoting the calls to the parent process.
This is necessary because, on Mac, querying the OS for helper application info from sandboxed content processes is unreliable and has buggy side effects.
For now, only use the new class on Mac.
Android and unix file changes r+ by gcp.
Windows files changes r+ by bobowen.
Sync messages review r+ by nfroyd.
MozReview-Commit-ID: 63BiS6VCxfn
Differential Revision: https://phabricator.services.mozilla.com/D15620
--HG--
extra : moz-landing-system : lando
Add a new nsExternalHelperAppService derived class named nsOSHelperAppServiceChild to be used for the MIME service, external helper app service, and external protocol service interfaces in child processes. nsOSHelperAppServiceChild overrides some methods used to get MIME and external protocol handler information from the OS and implements these methods by remoting the calls to the parent process.
This is necessary because, on Mac, querying the OS for helper application info from sandboxed content processes is unreliable and has buggy side effects.
For now, only use the new class on Mac.
Android and unix file changes r+ by gcp.
Windows files changes r+ by bobowen.
Sync messages review r+ by nfroyd.
MozReview-Commit-ID: 63BiS6VCxfn
Differential Revision: https://phabricator.services.mozilla.com/D15620
--HG--
extra : moz-landing-system : lando
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
Gabriele Svelto
Gijs Kruitbosch
Haik Aftandilian
arthur.iakab
Mark Banner
Sylvestre Ledru
Chris Peterson
Ted Mielczarek