TabGroup never really made any difference in which thread something go
dispatched to. This was the intended use, but development of TabGroups
with abstract main threads never made it that far. The good thing is
that thish makes it safe to also remove to the SystemGroup and instead
switch all SystemGroup dispatches to dispatches to main thread.
Timers for setTimeout and workers were the sole users of wrapped and
throttled event targets, that those throttled queues have been moved
to the BrowsingContextGroup and are now accessed explicitly.
The SchedulerEventTarget has been removed, since there are no longer a
separate event target for every TaskCategory. Instead a
LabellingEventTarget has been added to DocGroup to handle the case
where an event is dispatched do DocGroup or when an AbstractThread is
created using a DocGroup. This means that we'll actually label more
events correctly with the DocGroup that they belong to.
DocGroups have also been moved to BrowsingContextGroup.
Depends on D67636
Differential Revision: https://phabricator.services.mozilla.com/D65936
--HG--
extra : moz-landing-system : lando
In the Windows API, the maximum length for a path is MAX_PATH in general.
However, the Windows API has many functions that also have Unicode versions to
permit an extended-length path for a maximum total path length of 32,767
characters. To specify an extended-length path, use the "\\?\" prefix.
A path component which ends with a dot is not allowed for Windows API. However,
using the "\\?\" prefix can also resolved this issue.
This patch aims to fix the issues which are mentioned above by prepending the
prefix to the path of nsLocalFile if mDisableStringParsing is set to true.
Differential Revision: https://phabricator.services.mozilla.com/D67014
--HG--
extra : moz-landing-system : lando
Also move MOZ_MUST_USE before function declarations' specifiers and return type. While clang and gcc's __attribute__((warn_unused_result)) can appear before, between, or after function specifiers and return types, the [[nodiscard]] attribute must precede the function specifiers.
Also remove MOZ_MUST_USE from nsIMemoryReporter's function pointer typedefs. [[nodiscard]] is an attribute of a function's declaration, not the function's type, and thus can't be applied to function pointers or lambdas.
Differential Revision: https://phabricator.services.mozilla.com/D68138
--HG--
extra : moz-landing-system : lando
This is one of the efforts to reduce usage of `ShellExecuteByExplorer`
(bug 1620335).
The purpose of using `ShellExecuteByExplorer` in the scenario to open a
downloaded file is to support applications which are not compatible with
the mitigation policies of our process. When a downloaded file is an
executable, however, we prefer security to compatibility and in particular
we want to prevent binary planting on a user's download directory.
The proposed fix is to go to `ShellExecuteExW` straight if the target
file to launch is an executable.
Differential Revision: https://phabricator.services.mozilla.com/D66325
--HG--
extra : moz-landing-system : lando
This is one of the efforts to reduce usage of `ShellExecuteByExplorer`
(bug 1620335).
The purpose of using `ShellExecuteByExplorer` in the scenario to open a
downloaded file is to support applications which are not compatible with
the mitigation policies of our process. When a downloaded file is an
executable, however, we prefer security to compatibility and in particular
we want to prevent binary planting on a user's download directory.
The proposed fix is to go to `ShellExecuteExW` straight if the target
file to launch is an executable.
Differential Revision: https://phabricator.services.mozilla.com/D66325
--HG--
extra : moz-landing-system : lando
At shutdown, the stream transport service is not available and `free(aPtr)` happens synchronously. These warnings will always trigger and produce a lot of logspam.
Differential Revision: https://phabricator.services.mozilla.com/D61217
--HG--
extra : moz-landing-system : lando
It turned out that `ShellExecuteByExplorer` does not work on VDI such as Citrix
or Microsoft RemoteApp. This patch adds a fallback to the original launching
code if `ShellExecuteByExplorer` fails. This will be a temporary solution until
we find out a way to solve both interop issues `PreferSystem32Images` and VDI.
Differential Revision: https://phabricator.services.mozilla.com/D58054
--HG--
extra : moz-landing-system : lando
This removes various unused `#include "nsAutoPtr.h"` in `xpcom/`. Additionally
adds a few includes to the media stack.
Differential Revision: https://phabricator.services.mozilla.com/D58282
--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
The patch for Bug 1588975 specified the "open" verb to execute a target, but
the default verb is not always "open". For example, the default verb for a font
file is "preview". We should specify null verb to start the default operation.
Now we use `IShellDispatch2.ShellExecute` to ask explorer.exe to call
`ShellExecuteExW`. That method takes an optional `VARIANT` parameter as a verb.
According to https://devblogs.microsoft.com/oldnewthing/20140919-00/?p=44023,
we need to pass `VT_ERROR` to omit an optional parameter. If we pass
other values such as `nullptr` with `VT_BSTR` or `VT_EMPTY`, explorer.exe calls
`ShellExecuteExW` with the empty string `""` instead of `nullptr`, which is not
considered as a valid verb if the target file is not associated with any app.
Differential Revision: https://phabricator.services.mozilla.com/D54036
--HG--
extra : moz-landing-system : lando
Calling `AsWin32Error()` for the return value from `ShellExecuteByExplorer` can
cause the crash because it may not be a Win32 error. We simply return
`NS_ERROR_FILE_EXECUTION_FAILED` as we do in `nsProcess::RunProcess` or
`ShellExecuteWithIFile`.
We used to check the return value from `ShellExecuteExW` against `SE_ERR_NOASSOC`,
but it never happens because `SE_ERR_` is returned as `SHELLEXECUTEINFO::hInstApp`.
No worry about the no-association case because `IShellDispatch2.ShellExecute`
displays the "How do you want to open this file?" popup when needed.
Differential Revision: https://phabricator.services.mozilla.com/D54052
--HG--
extra : moz-landing-system : lando
The launcher process turns on the `PreferSystem32Images` mitigation policy for
the browser process. Since the mitigation policy is inherited, a process launched
by the browser process also has `PreferSystem32Images`. If an application which
does not support `PreferSystem32Images`, such as Skype for Business, is launched
via a hyperlink, a custom uri, or a downloaded file, it would fail to launch.
Bug 1567614 fixed this issue by introducing `mozilla::ShellExecuteByExplorer` to
`nsMIMEInfoWin::LoadUriInternal`. This patch introduces
`mozilla::ShellExecuteByExplorer` to two more places.
1. xul!nsLocalFile::Launch
This is invoked when a user opens a file from the Download Library, or a user
opens a downloaded file with the default application without saving it.
2. xul!nsMIMEInfoWin::LaunchWithFile
This is invoked when a user opens a downloaded file with a custom application
(configured in about:preference) without saving it.
*Why does this patch change worker.js?*
The mochitest dom/tests/browser/browser_test_new_window_from_content.js failed
if it was executed after dom/serviceworkers/test/browser_download.js in the
same batch. This was because browser_download.js launched Notepad to open
fake_download.bin.txt, preventing a new window from being opened in the
foreground in browser_test_new_window_from_content.js.
The test browser_download.js can verify downloaded data without opening an
associated application. So this patch adds the content-type to the response
header in order not to open Notepad on Windows.
Differential Revision: https://phabricator.services.mozilla.com/D52567
--HG--
extra : moz-landing-system : lando
In this change we:
- stop treating the nsPluginDirServiceProvider as a directory provider, as its
GetFile implementation was a no-op anyway - registering it didn't make any
difference.
- stop treating it as a class entirely, because the PLID getters were already
static, so instantiating it also didn't do anything.
- move IO from the plugin directory list provider and the Windows-only PLID
getters into nsPluginHost. This enables us to move it off of the main thread
later - the directory getting has to happen on the main thread, but we can
postpone further checks on the nsIFile instances.
- in the process, stop doing exists() calls on files because we can fail more
lazily. This allows us to remove more allowlist entries from
browser_startup_mainthreadio, though the `isDirectory` calls will actually
still cause IO - they don't seem to create IO markers in the profiler.
We will move this IO away from the main thread in subsequent commits.
Depends on D48328
Differential Revision: https://phabricator.services.mozilla.com/D48329
--HG--
extra : moz-landing-system : lando
In this change we:
- stop treating the nsPluginDirServiceProvider as a directory provider, as its
GetFile implementation was a no-op anyway - registering it didn't make any
difference.
- stop treating it as a class entirely, because the PLID getters were already
static, so instantiating it also didn't do anything.
- move IO from the plugin directory list provider and the Windows-only PLID
getters into nsPluginHost. This enables us to move it off of the main thread
later - the directory getting has to happen on the main thread, but we can
postpone further checks on the nsIFile instances.
- in the process, stop doing exists() calls on files because we can fail more
lazily. This allows us to remove more allowlist entries from
browser_startup_mainthreadio, though the `isDirectory` calls will actually
still cause IO - they don't seem to create IO markers in the profiler.
We will move this IO away from the main thread in subsequent commits.
Depends on D48328
Differential Revision: https://phabricator.services.mozilla.com/D48329
--HG--
extra : moz-landing-system : lando
Note that this code asserts it gets run in the parent process, so we can be sure that we never
want the content process sandbox-accessible dir or similar (though tbf, that seems odd given
we have DOM machinery to proxy from the child to here... but that's what happens today).
This will start using the actual temp dir even in the case of e.g. xpcshell, which normally
dependency-injects a different (also temp) dir and reuses it as the profile as well as temp
dir ( https://searchfox.org/mozilla-central/rev/03853a6e87c4a9405fce1de49e5d03b9e7a7a274/testing/xpcshell/head.js#1207-1226 )
if and only if anything calls do_get_profile .
I think this is likely OK... but if not, we'll have to come up with a more complicated
solution...
Differential Revision: https://phabricator.services.mozilla.com/D42950
--HG--
extra : moz-landing-system : lando