This passes around the "are we external" bit of load information a bunch,
such that the external protocol handling code has access to it.
In this bug and bug 1667468, I think ideally I would have used a check
if we're the OS default for a given protocol before continuing. However,
this information is currently unavailable on Linux (bug 1599713), and
worse, I believe is likely to remain unavailable in flatpak and other
such restricted environments (cf. bug 1618094 - we aren't able to find
out anything about protocol handlers from the OS).
So instead, we prompt the user if we are about to open a link passed
to us externally. There is a small chance this will be Breaking People's
Workflows, where I don't know whether anyone relies on Firefox happily
passing these URIs along to the relevant application (more convenient
than doing all the registry/API work yourself in scripts!) or anything
like that. To help with that, there's a pref,
`network.protocol-handler.prompt-from-external`, that can be created and
set to false to avoid prompting in this case.
Differential Revision: https://phabricator.services.mozilla.com/D103967
I am not conviced that we have all the correct MIME types and extensions here.
It also extremely hard to figure out what the correct information is.
We should drop this.
Differential Revision: https://phabricator.services.mozilla.com/D105358
This passes around the "are we external" bit of load information a bunch,
such that the external protocol handling code has access to it.
In this bug and bug 1667468, I think ideally I would have used a check
if we're the OS default for a given protocol before continuing. However,
this information is currently unavailable on Linux (bug 1599713), and
worse, I believe is likely to remain unavailable in flatpak and other
such restricted environments (cf. bug 1618094 - we aren't able to find
out anything about protocol handlers from the OS).
So instead, we prompt the user if we are about to open a link passed
to us externally. There is a small chance this will be Breaking People's
Workflows, where I don't know whether anyone relies on Firefox happily
passing these URIs along to the relevant application (more convenient
than doing all the registry/API work yourself in scripts!) or anything
like that. To help with that, there's a pref,
`network.protocol-handler.prompt-from-external`, that can be created and
set to false to avoid prompting in this case.
Differential Revision: https://phabricator.services.mozilla.com/D103967
Show save dialogue
***
Automaticly show Panel On Block
***
Keep Open/Save Dialogue with open panel
***
Keep User choise in downloadsView
***
Add Unblock option to Unblock panel
***
lint
***
add test
Differential Revision: https://phabricator.services.mozilla.com/D96448
Show save dialogue
***
Automaticly show Panel On Block
***
Keep Open/Save Dialogue with open panel
***
Keep User choise in downloadsView
***
Add Unblock option to Unblock panel
***
lint
***
add test
Differential Revision: https://phabricator.services.mozilla.com/D96448
This restores extension discovery logic to using the URL for requests where
there's no filename in the Content-Disposition header information, and where
the mimetype gives no indication of the 'correct' extension.
This is a short-term workaround for the larger issue that we should not have
bad local information for these mimetypes - fixing that is bug 1659008, but
requires using the extension to get a better mimetype, which this patch will
also help with.
Differential Revision: https://phabricator.services.mozilla.com/D97824
- Added pref to toggle permission feature
- Updated ContentDispatchChooser to check for permission and manage a multi dialog flow.
Differential Revision: https://phabricator.services.mozilla.com/D92945
- Added pref to toggle permission feature
- Updated ContentDispatchChooser to check for permission and manage a multi dialog flow.
Differential Revision: https://phabricator.services.mozilla.com/D92945
This changes two bits of Firefox that, together with the mime service, end up
very confused over webp + jpeg.
1) it changes contentAreaUtils.js' getDefaultExtension that if it gets an image
mimetype as the content type, it should ignore the URL. It doesn't have full channel
info so it can't really do better anyway. This fixes the context menu's "save image as..."
case.
2) it changes the external helper app service to do a few things slightly differently:
a. If we're told not to get an extension out of a URL, really don't. Don't just get the
filename and then get it from there anyway...
b. If we've got a suggested filename, and a primary extension for the mimetype,
and the extension on the file is not one of the known extensions for the mimetype,
replace it with the primary extension.
This fixes the link case.
It also adds tests for both of these mechanisms as well as "save image as."
Differential Revision: https://phabricator.services.mozilla.com/D92306
This changes two bits of Firefox that, together with the mime service, end up
very confused over webp + jpeg.
1) it changes contentAreaUtils.js' getDefaultExtension that if it gets an image
mimetype as the content type, it should ignore the URL. It doesn't have full channel
info so it can't really do better anyway. This fixes the context menu's "save image as..."
case.
2) it changes the external helper app service to do a few things slightly differently:
a. If we're told not to get an extension out of a URL, really don't. Don't just get the
filename and then get it from there anyway...
b. If we've got a suggested filename, and a primary extension for the mimetype,
and the extension on the file is not one of the known extensions for the mimetype,
replace it with the primary extension.
This fixes the link case.
It also adds tests for both of these mechanisms as well as "save image as."
Differential Revision: https://phabricator.services.mozilla.com/D92306
This changes two bits of Firefox that, together with the mime service, end up
very confused over webp + jpeg.
1) it changes contentAreaUtils.js' getDefaultExtension that if it gets an image
mimetype as the content type, it should ignore the URL. It doesn't have full channel
info so it can't really do better anyway. This fixes the context menu's "save image as..."
case.
2) it changes the external helper app service to do a few things slightly differently:
a. If we're told not to get an extension out of a URL, really don't. Don't just get the
filename and then get it from there anyway...
b. If we've got a suggested filename, and a primary extension for the mimetype,
and the extension on the file is not one of the known extensions for the mimetype,
replace it with the primary extension.
This fixes the link case.
It also adds tests for both of these mechanisms as well as "save image as."
Differential Revision: https://phabricator.services.mozilla.com/D92306
This changes two bits of Firefox that, together with the mime service, end up
very confused over webp + jpeg.
1) it changes contentAreaUtils.js' getDefaultExtension that if it gets an image
mimetype as the content type, it should ignore the URL. It doesn't have full channel
info so it can't really do better anyway. This fixes the context menu's "save image as..."
case.
2) it changes the external helper app service to do a few things slightly differently:
a. If we're told not to get an extension out of a URL, really don't. Don't just get the
filename and then get it from there anyway...
b. If we've got a suggested filename, and a primary extension for the mimetype,
and the extension on the file is not one of the known extensions for the mimetype,
replace it with the primary extension.
This fixes the link case.
It also adds tests for both of these mechanisms as well as "save image as."
Differential Revision: https://phabricator.services.mozilla.com/D92306
Also improve detection of types needing overwrite by using the final extension settled on for the
type.
I didn't fold PDF fully into this part, as it has different conditions for showing the radio button vs.
viewing internally from the downloads list.
Also fix intermittent bug 1641774 (wouldn't run in verify) by saving handler info at the beginning
of browser_download_open_with_internal_handler, instead of at the start of a subtest.
Differential Revision: https://phabricator.services.mozilla.com/D86651
Also improve detection of types needing overwrite by using the final extension settled on for the
type.
I didn't fold PDF fully into this part, as it has different conditions for showing the radio button vs.
viewing internally from the downloads list.
Differential Revision: https://phabricator.services.mozilla.com/D86651
The aim of the code we're modifying here is to block things in one browsingcontext
tree from opening external links in another browsingcontext tree (and causing the
external protocol dialog to show up for that tab/window) -- except if the other
browsingcontext into which something is being loaded is same-origin.
Unfortunately the pre-patch code assumed that it would find currentWindowGlobal
objects for each browsingcontext, and it turns out that's not guaranteed,
especially in the case of hidden iframes, which turn out to be quite commonly
used for external protocol launches.
This patch fixes this by continuing to move towards the root of the browsingcontext
tree even if there's no currentWindowGlobal (though logically speaking, this
should only be necessary for the first iteration of the loop, it seems easier to
just always check this). It also adds a test for this behaviour working.
Differential Revision: https://phabricator.services.mozilla.com/D83015
The aim of the code we're modifying here is to block things in one browsingcontext
tree from opening external links in another browsingcontext tree (and causing the
external protocol dialog to show up for that tab/window) -- except if the other
browsingcontext into which something is being loaded is same-origin.
Unfortunately the pre-patch code assumed that it would find currentWindowGlobal
objects for each browsingcontext, and it turns out that's not guaranteed,
especially in the case of hidden iframes, which turn out to be quite commonly
used for external protocol launches.
This patch fixes this by continuing to move towards the root of the browsingcontext
tree even if there's no currentWindowGlobal (though logically speaking, this
should only be necessary for the first iteration of the loop, it seems easier to
just always check this). It also adds a test for this behaviour working.
Differential Revision: https://phabricator.services.mozilla.com/D83015
There's no use case for stateful comparators, so they can be just plain
function pointers.
This is used in some hot places like CSS selector matching.
Differential Revision: https://phabricator.services.mozilla.com/D77084
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
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
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
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
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
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 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
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
This does many things:
1) stops producing (and consuming) `FennecJNI*` JNI wrappers
2) removes the :app and :thirdparty Gradle projects
3) removes relevant pieces of the Gradle target configuration
4) updates lints
5) purges old configurations
After this commit, the `mobile/android` project/application builds
only GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D46536
--HG--
extra : moz-landing-system : lando
Similarly to nsITabParent, TabChild is exposed to frontend code via nsITabChild. It's not clear what the future of this interface will be, but for now we can just rename it to nsIBrowserChild.
Differential Revision: https://phabricator.services.mozilla.com/D28134
--HG--
rename : dom/interfaces/base/nsITabChild.idl => dom/interfaces/base/nsIBrowserChild.idl
extra : rebase_source : a6c42a661e35b19e46c60f6f6a6f3dab64c0a1bc
extra : histedit_source : 1eb475bd840bf37a3f86294685c9b3c250684e79
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
If class A is derived from class B, then an instance of class A can be
converted to B via a static cast, so a slower QI is not needed.
Differential Revision: https://phabricator.services.mozilla.com/D6861
--HG--
extra : moz-landing-system : lando
Correctness improvements:
* UTF errors are handled safely per spec instead of dangerously truncating
strings.
* There are fewer converter implementations.
Performance improvements:
* The old code did exact buffer length math, which meant doing UTF math twice
on each input string (once for length calculation and another time for
conversion). Exact length math is more complicated when handling errors
properly, which the old code didn't do. The new code does UTF math on the
string content only once (when converting) but risks allocating more than
once. There are heuristics in place to lower the probability of
reallocation in cases where the double math avoidance isn't enough of a
saving to absorb an allocation and memcpy.
* Previously, in UTF-16 <-> UTF-8 conversions, an ASCII prefix was optimized
but a single non-ASCII code point pessimized the rest of the string. The
new code tries to get back on the fast ASCII path.
* UTF-16 to Latin1 conversion guarantees less about handling of out-of-range
input to eliminate an operation from the inner loop on x86/x86_64.
* When assigning to a pre-existing string, the new code tries to reuse the
old buffer instead of first releasing the old buffer and then allocating a
new one.
* When reallocating from the new code, the memcpy covers only the data that
is part of the logical length of the old string instead of memcpying the
whole capacity. (For old callers old excess memcpy behavior is preserved
due to bogus callers. See bug 1472113.)
* UTF-8 strings in XPConnect that are in the Latin1 range are passed to
SpiderMonkey as Latin1.
New features:
* Conversion between UTF-8 and Latin1 is added in order to enable faster
future interop between Rust code (or otherwise UTF-8-using code) and text
node and SpiderMonkey code that uses Latin1.
MozReview-Commit-ID: JaJuExfILM9
Much like the component manager, many of the strings that we use for category
manager entries are statically allocated. There's no need to duplicate these
strings.
This patch changes the category manager APIs to take nsACStrings rather than
raw pointers, and to pass literal nsCStrings when we know we have a literal
string to begin with. When adding the category entry, it then skips making
copies of any strings with the LITERAL flag.
MozReview-Commit-ID: EJEcYSdNMWs
***
amend-catman
--HG--
extra : source : aa9a8f18e98f930a3d8359565eef02f3f6efc5f9
extra : absorb_source : 81a22ab26ee8017ac43321ff2c987d8096182d37
Much like the component manager, many of the strings that we use for category
manager entries are statically allocated. There's no need to duplicate these
strings.
This patch changes the category manager APIs to take nsACStrings rather than
raw pointers, and to pass literal nsCStrings when we know we have a literal
string to begin with. When adding the category entry, it then skips making
copies of any strings with the LITERAL flag.
MozReview-Commit-ID: EJEcYSdNMWs
***
amend-catman
--HG--
extra : rebase_source : 4f70e7b296ecf3b52a4892c92155c7c163d424d2
Mimeinfo returned for the generic application/octet-stream content
type is usually irrelevant to the file extension, getting mimeinfo
from extension itself is more reliable.
Also prefer file extension over application/octet-stream content tyope
when lookup in extras.
MozReview-Commit-ID: A9Q2NFAwQ7b
--HG--
extra : rebase_source : 4206cbfd898fb12b2415ef751a74d1bdeee26a2d
Gijs Kruitbosch
Alexis Beingessner
Tom Schuster
Noemi Erli
Butkovits Atila
Sebastian Streich
Bogdan Tara
pbz
Dorel Luca
Csoregi Natalia
Narcis Beleuzu
Simon Giesecke
Razvan Maries
Cosmin Sabou
Adam Gashlin
owlishDeveloper
Marco Bonardo
Emilio Cobos Álvarez
Jared Wein
Jon Bauman
Eric Rahm
sonakshi
Masatoshi Kimura
Matt Woodrow
shindli
Emma Malysz
Chris Peterson
Gabriele Svelto
Jean-Yves Avenard
Sean Feng
Boris Zbarsky
Nick Alexander
Nika Layzell
Ryan Hunt
Haik Aftandilian
arthur.iakab
Alex Gaynor
Jonathan Kingston
Christoph Kerschbaumer
Kershaw Chang
Ehsan Akhgari
Sylvestre Ledru
Andrew McCreight
Henri Sivonen
Kris Maglione
Brindusan Cristian
Jan Horak
Mark Banner