I was hitting the assertion and was investigating a bit. This makes the
registration a bit faster, but doesn't change behavior.
Depends on D103567
Differential Revision: https://phabricator.services.mozilla.com/D103568
This is an issue I found while going through this code and
writing/debugging a test for the bug at hand. Without this, the test in
the actual fix for this bug will fail to actually reuse the preloaded
stylesheet.
It seems reasonable to assume that the intersection of quirks mode
documents using link preload headers is small (and in that case we'd
parse the sheet twice, but oh well).
Differential Revision: https://phabricator.services.mozilla.com/D103567
Bug 1643204 really only papered over the issue of the active state being
messed up / the document becoming visible internally without notifying
media.
Bug 1572798 notifies media properly so that the visibility state is
consistent with what media thinks the visibility state is, so I think
there's no longer a reason to do this.
No other browser passes the test added in bug 1643204.
Differential Revision: https://phabricator.services.mozilla.com/D100836
To clarify the two separate SubDialog managers managed by TabDialogManager, this patch renames `_.dialogManager` to `._tabDialogManager`.
Depends on D100066
Differential Revision: https://phabricator.services.mozilla.com/D100955
To clarify the two separate SubDialog managers managed by TabDialogManager, this patch renames `_.dialogManager` to `._tabDialogManager`.
Depends on D100066
Differential Revision: https://phabricator.services.mozilla.com/D100955
To clarify the two separate SubDialog managers managed by TabDialogManager, this patch renames `_.dialogManager` to `._tabDialogManager`.
Depends on D100066
Differential Revision: https://phabricator.services.mozilla.com/D100955
In the case we click a link from inside the frame, we don't want to
check for activation from the parent window but ourselves.
It feels like using the sourceWindowContext for these checks is always
the right thing to do, but it's not always possible if we set the
location.href from an out-of-process parent. In this case, we fall back
to consuming user activation on the iframe itself. This is tested in
browbrowser_protocol_ask_dialog.js when run with fission enabled.
We could consider making the user activation stuff more
multiprocess-friendly, but it's not clear to me it's worth it for this
particular edge case.
Differential Revision: https://phabricator.services.mozilla.com/D100578
In the case we click a link from inside the frame, we don't want to
check for activation from the parent window but ourselves.
It feels like using the sourceWindowContext for these checks is always
the right thing to do, but it's not always possible if we set the
location.href from an out-of-process parent. In this case, we fall back
to consuming user activation on the iframe itself. This is tested in
browbrowser_protocol_ask_dialog.js when run with fission enabled.
We could consider making the user activation stuff more
multiprocess-friendly, but it's not clear to me it's worth it for this
particular edge case.
Differential Revision: https://phabricator.services.mozilla.com/D100578
The finished downloads were removed, which meant that the next time the
download code asynchronously refreshed them, they were smaller than the last
time that they checked, which meant we got another `onChange` notification
for the download (which would still be finished / in error state), which
confused the test which expected 1 notification per download.
To avoid this, we clear finished downloads after each iteration inside the
test, instead of at the end.
Differential Revision: https://phabricator.services.mozilla.com/D100149
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
Bug 1583109 introduced new function templates StringJoin and StringJoinAppend.
These are now used to replace several custom loops across the codebase that
implement string-joining algorithms to simplify the code.
Differential Revision: https://phabricator.services.mozilla.com/D98750
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
Bug 1583109 introduced new function templates StringJoin and StringJoinAppend.
These are now used to replace several custom loops across the codebase that
implement string-joining algorithms to simplify the code.
Differential Revision: https://phabricator.services.mozilla.com/D98750
Only for top windows because for nested iframes they could get around
this without being noticed by reloading themselves which is not great.
Differential Revision: https://phabricator.services.mozilla.com/D98775
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 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)
