The component that handles MIME type information will consult whatever
the OS uses as a registry of file types / applications; in the past
this caused problems for sandboxing on macOS and then Windows, so IPC was
used to remote those queries to the parent process.
We've also been having similar problems on Linux, and none of the
infrastructure here seems to be OS-specific; therefore I've removed the
`#ifdef` so that we always use IPC.
Differential Revision: https://phabricator.services.mozilla.com/D145823
This patch won't actually build, because a few bits of code are used
for both nsIFactory::createInstance and static components, and static
components are not fixed until the next patch.
The first place is nsLoadGroupConstructor, which uses an nsIFactory
macro to create a static component constructor. (This could be worked
around by expanding the macro to the state before this patch.)
The other issue is that nsAppShellConstructor is used in an nsIFactory
on OSX, but as a static component on all other platforms. This could
be worked around by wrapping nsAppShellConstructor in an adaptor that
passes in the extra null argument to nsAppShellConstructor.
Differential Revision: https://phabricator.services.mozilla.com/D146456
This test involves clicking on a link to a .bin file. In the Mac test environment, this is given the macbinary content type. This test assumes that it will be octet-stream (another valid content type for the bin extension) and sets the alwaysAskBeforeHandling flag for that, so the dialog never shows up. However, another subtest needs octet-stream to prompt as well, so set the always ask for both.
Differential Revision: https://phabricator.services.mozilla.com/D145547
This is a medium sized patch to legacy download construction. It takes
advantage of the new property added in Bug 1762033 to prevent the
downloads panel from being automatically shown when a download is added
after an interaction with the unknown content type dialog or the file
picker dialog. I chose to not do the same for failed transfers since I
thought it might serve some use, but that might be wrong. I don't know
if there's a way to test the dialog that appears when you download an
executable without going through the same path I adjusted with the
patch. It seems like it's covered but I could be wrong. Also add a test
to cover these changes from the bottom up. Thanks and apologies for my
sloppy C++, though I'm sure I'll learn a lot more from the review 😅
Differential Revision: https://phabricator.services.mozilla.com/D145312
This test involves clicking on a link to a .bin file. In the Mac test environment, this is given the macbinary content type. This test assumes that it will be octet-stream (another valid content type for the bin extension) and sets the alwaysAskBeforeHandling flag for that, so the dialog never shows up. However, another subtest needs octet-stream to prompt as well, so set the always ask for both.
Differential Revision: https://phabricator.services.mozilla.com/D145547
With MOZ_FORMAT_PRINTF annotations, the compiler expects a wchar_t*, and
it won't automatically consider char16ptr_t to be compatible with that.
While handling strings, there's one case of formatting that doesn't need
to use %S at all.
Differential Revision: https://phabricator.services.mozilla.com/D144919
The patch appears to have caused an increase in timeouts, but based on a
quick scan of the log, it appears it's due to the test running right
against the time limit, rather than due to the test deadlocking or
similar.
Differential Revision: https://phabricator.services.mozilla.com/D145235
When downloading a file, we check for existing mime types and construct
a new one if it's unrecognized. Mime types have a flag,
alwaysAskBeforeHandling, that determines whether the unknown content
type dialog should be opened before handling the file. Before bug
1733492, the default value for that flag was simply true. Since the new
downloads flow is intended to avoid unnecessary steps, the default value
was changed to the inverted value of the new downloads panel
improvements pref. This patch adds a new pref that the mime info
constructor will read in configuring the flag's value. If the
improvements pref is not enabled, then the flag will be true, so the UCT
dialog will open. If the improvements pref is enabled, then it'll use
the value of the new pref. Also add a an interface for the pref to the
about:preferences UI, and automatically migrate a false value for
browser.download.improvements_to_download_panel to a true value for this
pref. I'm updating some tangentially related test files since they
happen to be touched slightly by this change. Strictly speaking they
would still work, but if the pref value was somehow changed from the
default they would fail.
Differential Revision: https://phabricator.services.mozilla.com/D143002
When downloading a file, we check for existing mime types and construct
a new one if it's unrecognized. Mime types have a flag,
alwaysAskBeforeHandling, that determines whether the unknown content
type dialog should be opened before handling the file. Before bug
1733492, the default value for that flag was simply true. Since the new
downloads flow is intended to avoid unnecessary steps, the default value
was changed to the inverted value of the new downloads panel
improvements pref. This patch adds a new pref that the mime info
constructor will read in configuring the flag's value. If the
improvements pref is not enabled, then the flag will be true, so the UCT
dialog will open. If the improvements pref is enabled, then it'll use
the value of the new pref. Also add a an interface for the pref to the
about:preferences UI, and automatically migrate a false value for
browser.download.improvements_to_download_panel to a true value for this
pref. I'm updating some tangentially related test files since they
happen to be touched slightly by this change. Strictly speaking they
would still work, but if the pref value was somehow changed from the
default they would fail.
Differential Revision: https://phabricator.services.mozilla.com/D143002