Added two new tests to ensure the external protocol dialogs behave correctly if
ContentDispatchChooser is passed a null principal, or no principal at all.
Differential Revision: https://phabricator.services.mozilla.com/D95747
- 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
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
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
Per matrix discussion, this is safer to uplift (instead of relying on
the RedirectSink being released on the main thread).
Differential Revision: https://phabricator.services.mozilla.com/D91270
PreloaderBase -> RedirectSink -> PreloaderBase is a strong,
non-cycle-collected reference cycle, which in cases where we don't drop
the channel because we never get an NotifyStop notification, it can
cause leaks.
I'm investigating the root cause of the lack of NotifyStop, but this
should fix the leak and is correct anyhow.
Move the class to the cpp file to ease debugging and changes.
Differential Revision: https://phabricator.services.mozilla.com/D91259
This patch was generated by running:
```
perl -p -i \
-e 's/^(\s+)([a-zA-Z0-9.]+) = NS_ConvertUTF8toUTF16\((.*)\);/\1CopyUTF8toUTF16(\3, \2);/;' \
-e 's/^(\s+)([a-zA-Z0-9.]+) = NS_ConvertUTF16toUTF8\((.*)\);/\1CopyUTF16toUTF8(\3, \2);/;' \
$FILE
```
against every .cpp and .h in mozilla-central, and then fixing up the
inevitable errors that happen as a result of matching C++ expressions with
regexes. The errors fell into three categories:
1. Calling the convert functions with `std::string::c_str()`; these were
changed to simply pass the string instead, relying on implicit conversion
to `mozilla::Span`.
2. Calling the convert functions with raw pointers, which is not permitted
with the copy functions; these were changed to invoke `MakeStringSpan` first.
3. Other miscellaneous errors resulting from over-eager regexes and/or the
replacement not being type-aware. These changes were reverted.
Differential Revision: https://phabricator.services.mozilla.com/D88903
Now that we've concluded no immediate action is needed for slow
ShellExecuteByExplorer, `SHELLEXECUTEBYEXPLORER_DURATION_MS` is
no longer needed.
Differential Revision: https://phabricator.services.mozilla.com/D86143
Not just the one that takes a channel. This fixes the issue.
Also, as an optimization, avoid creating a timer if we're used already
or we have already one.
Differential Revision: https://phabricator.services.mozilla.com/D87267
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
This patch adds a new measurement to the histogram about the elapsed time
of `ShellExecuteByExplorer`. If ShellExecuteByExplorer takes long in
a considerable number of instances, we need to consider fixing bug 1646986.
Differential Revision: https://phabricator.services.mozilla.com/D84407
Having two classes in the inheritance chain inherit from SupportsWeakPtr
now won't compile, but you can use WeakPtr<Derived> when any base class
inherits from SupportsWeakPtr.
Differential Revision: https://phabricator.services.mozilla.com/D83674
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
CLOSED TREE
Backed out changeset 51d7c644a1e6 (bug 1650163)
Backed out changeset 3d2b6908447a (bug 1650163)
Backed out changeset 79141707d47b (bug 1650163)
The WPT a-download-click-404.html requires this behaviour for links with the download attribute, and this is also the current behaviour for Content-Disposition: Attachment (see bug 1604308).
This previously worked because the parent process version of nsDocumentOpenInfo failed (with NS_ERROR_FILE_NOT_FOUND), but the error code was discarded and we forwarded the channel to the content process. The content process version then would then return NS_ERROR_WONT_HANDLE_CONTENT since the load requires downloading, but we don't allow that in the content process. This new error code is one that doesn't have an associated error page (unlilke the original error), so was silently discarded.
Differential Revision: https://phabricator.services.mozilla.com/D81014
When we hit the stylesheet cache for an existing stylesheet in a
different document:
* There's no existing preload in the PreloadService (because the sheet
was loaded in another document).
* We don't create a PreloaderBase (because we don't trigger a load at
all).
* And thus we believe the load has just errored, which is wrong...
Fix it by properly passing through the "already complete" status from
PreloadStyle.
Note that there's still another issue, which is that we'd still hit this
broken path if two stylesheets with the same URI are loading in
different documents and the CSS loader coalesces them.
For that, I think we'd have to make SheetLoadData the thing that
actually implements PreloaderBase. This is kind of an obscure case, and
SheetLoadData has a pretty complex lifetime already (keeps alive a whole
lot of stuff), so I'd prefer to do this in a separate bug.
Differential Revision: https://phabricator.services.mozilla.com/D80289
We probably should remove the referrer policy check altogether in
bug 1642591, but the preload code still uses the whole referrer as the
key for css, which the css loader stopped doing in bug 1599160.
So this should be an uncontroversial simplification.
Differential Revision: https://phabricator.services.mozilla.com/D79810
This removes the diagnostic warnings which used to be logged when the
Large-Allocation header was present, but failed to switch into a
Large-Allocation process. Due to the low adoption of the header, this shouldn't
be too large of a problem, but we can look into re-adding the diagnostics if
needed in the future.
The new codepath no longer performs multiple network requests for
Large-Allocation resources, and now relies on the battle-tested
DocumentLoadListener codepath for process switching.
Differential Revision: https://phabricator.services.mozilla.com/D78998
This removes the diagnostic warnings which used to be logged when the
Large-Allocation header was present, but failed to switch into a
Large-Allocation process. Due to the low adoption of the header, this shouldn't
be too large of a problem, but we can look into re-adding the diagnostics if
needed in the future.
The new codepath no longer performs multiple network requests for
Large-Allocation resources, and now relies on the battle-tested
DocumentLoadListener codepath for process switching.
Differential Revision: https://phabricator.services.mozilla.com/D78998
This patch adds the following constraints:
- close the dialog when the originating context navigates;
- close the dialog when the originating context closes / goes away;
- do not allow more than 1 dialog at a time;
Differential Revision: https://phabricator.services.mozilla.com/D77029
I'm about to introduce the concept of "Loader principal" (as in "the
principal of the CSS loader"), and SheetLoadData already has an
mLoaderPrincipal.
However SheetLoadData's principal is just the triggering principal (the
principal that initiated the load). So name it that with consistency
with SheetInfo::mTriggeringPrincipal etc.
Differential Revision: https://phabricator.services.mozilla.com/D77613
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 was a bit of pain to track down, because some code was allowing an ID of 0, and creating a request context to match, but other code was treating 0 as invalid.
Differential Revision: https://phabricator.services.mozilla.com/D76652
Which is the spec term. nsIStyleSheetLinkingElement is even more
confusing since it may not be an element at all (see: processing
instructions).
Differential Revision: https://phabricator.services.mozilla.com/D76071
In this bug we're moving away from monolithic JNI headers to class-specific
headers so that we don't have to rebuild the world every time we make a change
to a JNI interface.
Differential Revision: https://phabricator.services.mozilla.com/D75367
Previously this would typically set GRE_HOME to /data/data/org.mozilla.geckoview.test,
even though org.mozilla.geckoview.test is not normally installed when running
xpcshell tests -- a non-existent directory in a privileged location!
The new location, remoteBinDir, is typically /data/local/xpcb, the location of the
xpcshell executable.
Differential Revision: https://phabricator.services.mozilla.com/D74938