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
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
Tom Schuster
Markus Stange
Simon Giesecke
Gijs Kruitbosch
smolnar
Sylvestre Ledru
longsonr
Mark Banner
Barret Rennie
Noemi Erli
Moritz Birghan
Emilio Cobos Álvarez
Butkovits Atila
Paul Zuehlcke
Micah Tigley
Bogdan Tara
Csoregi Natalia
Paul Dill
Narcis Beleuzu
Sebastian Streich