Native Windows apps (including but not limited to IE, old Edge, and Notepad) does not automatically resolve shell links (.lnk), so this patch follows their behavior.
Differential Revision: https://phabricator.services.mozilla.com/D73546
This drops `followLinks` as 1) it has been no-op on UNIX for a long time and 2) its Windows implementation never had a proper symlink support.
Differential Revision: https://phabricator.services.mozilla.com/D75569
This drops `followLinks` as 1) it has been no-op on UNIX for a long time and 2) its Windows implementation never had a proper symlink support.
Differential Revision: https://phabricator.services.mozilla.com/D75569
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/D75366
Bug 1536796 introduces "\\?\" prefix (DOS device specifier) to Windows file
paths. At the moment, the prefix is only prepended to the file paths that start
with a disk designator and a backslash.
On the other hands, IsBlockedUNCPath blocks file paths that start with "\\" in
Windows and that includes DOS device paths (the cases mentioned above).
Thus, this patch prevents DOS device paths from being treating as UNC paths in
IsBlockedUNCPath.
Differential Revision: https://phabricator.services.mozilla.com/D73621
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
If an XPIDL interface has a method or attribute that is [notxpcom],
then it is implicitly treated as [builtinclass], even if it is not
marked as such. For clarity, this patch goes through and marks every
place that relies on this behavior (aside from some test code).
Differential Revision: https://phabricator.services.mozilla.com/D30714
--HG--
extra : moz-landing-system : lando
I am 90% sure that this is wrong but this is the only way I can get it to
compile and work. Unlike other examples of supporting MOZ_DBG it only declares
an operator for `nsIURI* not` `const nsIURI`. I had to drop the const because
then I couldn't call GetSpec as it isn't marked const. I had to switch to a
pointer since otherwise it would complain about virtual methods.
Still in practice this works, I think it is rare that we hold an nsIURI in
anything other than a pointer and same for the constness.
Differential Revision: https://phabricator.services.mozilla.com/D25669
--HG--
extra : rebase_source : 9760674375563ec312568caf4a5ad46facfb6f68
clang's -Wmissing-prototypes option identifies global functions that can be made static (because they're only called from one compilation unit) or removed (if they're never called). The .cpp files defining these functions did not include the headers with the corresponding function prototypes used by other compilation units. Including a header file in its corresponding .cpp file can help catch mismatched declarations and definitions.
xpcom/components/nsCategoryManager.cpp:637:6 [-Wmissing-prototypes] no previous prototype for function 'NS_CreateServicesFromCategory'
xpcom/io/nsPipe3.cpp:1824:10 [-Wmissing-prototypes] no previous prototype for function 'nsPipeConstructor'
xpcom/io/nsStringStream.cpp:475:10 [-Wmissing-prototypes] no previous prototype for function 'nsStringInputStreamConstructor'
xpcom/threads/ThreadDelay.cpp:18:6 [-Wmissing-prototypes] no previous prototype for function 'DelayForChaosMode'
Differential Revision: https://phabricator.services.mozilla.com/D23265
--HG--
extra : rebase_source : a2085a090394a5d3f5c319258b782a5d9f217751
extra : source : 18c3e569ff15987eb200c62eaa9f4943ff08cb25
clang's -Wmissing-prototypes option identifies global functions that can be made static (because they're only called from one compilation unit) or removed (if they're never called).
xpcom/base/Logging.cpp:85:13 [-Wmissing-prototypes] no previous prototype for function 'ToLogStr'
xpcom/base/Logging.cpp:132:13 [-Wmissing-prototypes] no previous prototype for function 'ExpandPIDMarker'
xpcom/base/LogModulePrefWatcher.cpp:37:6 [-Wmissing-prototypes] no previous prototype for function 'ResetExistingPrefs'
xpcom/base/LogModulePrefWatcher.cpp:109:6 [-Wmissing-prototypes] no previous prototype for function 'LoadExistingPrefs'
xpcom/base/nsCycleCollector.cpp:212:6 [-Wmissing-prototypes] no previous prototype for function 'SuspectUsingNurseryPurpleBuffer'
xpcom/components/nsComponentManager.cpp:421:31 [-Wmissing-prototypes] no previous prototype for function 'begin'
xpcom/components/nsComponentManager.cpp:427:31 [-Wmissing-prototypes] no previous prototype for function 'end'
xpcom/ds/Dafsa.cpp:23:6 [-Wmissing-prototypes] no previous prototype for function 'GetNextOffset'
xpcom/ds/Dafsa.cpp:55:6 [-Wmissing-prototypes] no previous prototype for function 'IsEOL'
xpcom/ds/Dafsa.cpp:62:6 [-Wmissing-prototypes] no previous prototype for function 'IsMatch'
xpcom/ds/Dafsa.cpp:70:6 [-Wmissing-prototypes] no previous prototype for function 'IsEndCharMatch'
xpcom/ds/Dafsa.cpp:78:6 [-Wmissing-prototypes] no previous prototype for function 'GetReturnValue'
xpcom/ds/Dafsa.cpp:91:5 [-Wmissing-prototypes] no previous prototype for function 'LookupString'
xpcom/io/CocoaFileUtils.mm:195:13 [-Wmissing-prototypes] no previous prototype for function 'GetQuarantinePropKey'
xpcom/io/CocoaFileUtils.mm:203:24 [-Wmissing-prototypes] no previous prototype for function 'CreateQuarantineDictionary'
xpcom/rust/gtest/bench-collections/Bench.cpp:65:11 [-Wmissing-prototypes] no previous prototype for function 'MyRand'
xpcom/rust/gtest/bench-collections/Bench.cpp:85:6 [-Wmissing-prototypes] no previous prototype for function 'Bench_Cpp_unordered_set'
xpcom/rust/gtest/bench-collections/Bench.cpp:125:6 [-Wmissing-prototypes] no previous prototype for function 'Bench_Cpp_PLDHashTable'
xpcom/rust/gtest/bench-collections/Bench.cpp:166:6 [-Wmissing-prototypes] no previous prototype for function 'Bench_Cpp_MozHashSet'
xpcom/tests/gtest/TestAtoms.cpp:114:6 [-Wmissing-prototypes] no previous prototype for function 'isStaticAtom'
xpcom/tests/gtest/TestCallTemplates.cpp:72:6 [-Wmissing-prototypes] no previous prototype for function 'JustTestingCompilation'
xpcom/tests/gtest/TestCOMPtr.cpp:87:10 [-Wmissing-prototypes] no previous prototype for function 'CreateIFoo'
xpcom/tests/gtest/TestCOMPtr.cpp:98:6 [-Wmissing-prototypes] no previous prototype for function 'set_a_IFoo'
xpcom/tests/gtest/TestCOMPtr.cpp:105:16 [-Wmissing-prototypes] no previous prototype for function 'return_a_IFoo'
xpcom/tests/gtest/TestCOMPtr.cpp:164:10 [-Wmissing-prototypes] no previous prototype for function 'CreateIBar'
xpcom/tests/gtest/TestCOMPtr.cpp:175:6 [-Wmissing-prototypes] no previous prototype for function 'AnIFooPtrPtrContext'
xpcom/tests/gtest/TestCOMPtr.cpp:177:6 [-Wmissing-prototypes] no previous prototype for function 'AVoidPtrPtrContext'
xpcom/tests/gtest/TestCOMPtr.cpp:179:6 [-Wmissing-prototypes] no previous prototype for function 'AnISupportsPtrPtrContext'
xpcom/tests/gtest/TestCOMPtr.cpp:263:6 [-Wmissing-prototypes] no previous prototype for function 'Comparison'
xpcom/tests/gtest/TestCOMPtr.cpp:298:6 [-Wmissing-prototypes] no previous prototype for function 'DontAddRef'
xpcom/tests/gtest/TestCRT.cpp:17:5 [-Wmissing-prototypes] no previous prototype for function 'sign'
xpcom/tests/gtest/TestDeadlockDetector.cpp:62:6 [-Wmissing-prototypes] no previous prototype for function 'DisableCrashReporter'
xpcom/tests/gtest/TestDeadlockDetector.cpp:74:5 [-Wmissing-prototypes] no previous prototype for function 'Sanity_Child'
xpcom/tests/gtest/TestDeadlockDetector.cpp:95:5 [-Wmissing-prototypes] no previous prototype for function 'Sanity2_Child'
xpcom/tests/gtest/TestDeadlockDetector.cpp:159:5 [-Wmissing-prototypes] no previous prototype for function 'Sanity4_Child'
xpcom/tests/gtest/TestDeadlockDetector.cpp:182:5 [-Wmissing-prototypes] no previous prototype for function 'Sanity5_Child'
xpcom/tests/gtest/TestDeadlockDetector.cpp:303:5 [-Wmissing-prototypes] no previous prototype for function 'ContentionNoDeadlock_Child'
xpcom/tests/gtest/TestHashtables.cpp:88:6 [-Wmissing-prototypes] no previous prototype for function 'testTHashtable'
xpcom/tests/gtest/TestHashtables.cpp:205:10 [-Wmissing-prototypes] no previous prototype for function 'CreateIFoo'
xpcom/tests/gtest/TestMoveString.cpp:25:6 [-Wmissing-prototypes] no previous prototype for function 'SetAsOwned'
xpcom/tests/gtest/TestMoveString.cpp:34:6 [-Wmissing-prototypes] no previous prototype for function 'ExpectTruncated'
xpcom/tests/gtest/TestMoveString.cpp:40:6 [-Wmissing-prototypes] no previous prototype for function 'ExpectNew'
xpcom/tests/gtest/TestMruCache.cpp:52:11 [-Wmissing-prototypes] no previous prototype for function 'MakeStringKey'
xpcom/tests/gtest/TestMultiplexInputStream.cpp:106:34 [-Wmissing-prototypes] no previous prototype for function 'CreateStreamHelper'
xpcom/tests/gtest/TestNonBlockingAsyncInputStream.cpp:62:10 [-Wmissing-prototypes] no previous prototype for function 'ReadSegmentsFunction'
xpcom/tests/gtest/TestNsDeque.cpp:240:6 [-Wmissing-prototypes] no previous prototype for function 'CheckIfQueueEmpty'
xpcom/tests/gtest/TestNsRefPtr.cpp:105:10 [-Wmissing-prototypes] no previous prototype for function 'CreateFoo'
xpcom/tests/gtest/TestNsRefPtr.cpp:116:6 [-Wmissing-prototypes] no previous prototype for function 'set_a_Foo'
xpcom/tests/gtest/TestNsRefPtr.cpp:123:13 [-Wmissing-prototypes] no previous prototype for function 'return_a_Foo'
xpcom/tests/gtest/TestNsRefPtr.cpp:391:6 [-Wmissing-prototypes] no previous prototype for function 'AnFooPtrPtrContext'
xpcom/tests/gtest/TestNsRefPtr.cpp:392:6 [-Wmissing-prototypes] no previous prototype for function 'AVoidPtrPtrContext'
xpcom/tests/gtest/TestPLDHash.cpp:33:6 [-Wmissing-prototypes] no previous prototype for function 'TestCrashyOperation'
xpcom/tests/gtest/TestPipes.cpp:98:10 [-Wmissing-prototypes] no previous prototype for function 'TestPipe'
xpcom/tests/gtest/TestPipes.cpp:212:10 [-Wmissing-prototypes] no previous prototype for function 'TestShortWrites'
xpcom/tests/gtest/TestPipes.cpp:354:6 [-Wmissing-prototypes] no previous prototype for function 'RunTests'
xpcom/tests/gtest/TestPLDHash.cpp:90:6 [-Wmissing-prototypes] no previous prototype for function 'InitCapacityOk_InitialLengthTooBig'
xpcom/tests/gtest/TestPLDHash.cpp:95:6 [-Wmissing-prototypes] no previous prototype for function 'InitCapacityOk_InitialEntryStoreTooBig'
xpcom/tests/gtest/TestPLDHash.cpp:102:6 [-Wmissing-prototypes] no previous prototype for function 'InitCapacityOk_EntrySizeTooBig'
xpcom/tests/gtest/TestSlicedInputStream.cpp:111:20 [-Wmissing-prototypes] no previous prototype for function 'CreateSeekableStreams'
xpcom/tests/gtest/TestSlicedInputStream.cpp:125:20 [-Wmissing-prototypes] no previous prototype for function 'CreateNonSeekableStreams'
xpcom/tests/gtest/TestStrings.cpp:471:6 [-Wmissing-prototypes] no previous prototype for function 'test_assign_helper'
xpcom/tests/gtest/TestTArray.cpp:60:22 [-Wmissing-prototypes] no previous prototype for function 'DummyArray'
xpcom/tests/gtest/TestTArray.cpp:72:22 [-Wmissing-prototypes] no previous prototype for function 'FakeHugeArray'
xpcom/tests/gtest/TestThrottledEventQueue.cpp:96:6 [-Wmissing-prototypes] no previous prototype for function 'Enqueue'
xpcom/threads/BlockingResourceBase.cpp:86:6 [-Wmissing-prototypes] no previous prototype for function 'PrintCycle'
xpcom/threads/CPUUsageWatcher.cpp:41:10 [-Wmissing-prototypes] no previous prototype for function 'GetMicroseconds'
xpcom/threads/CPUUsageWatcher.cpp:46:10 [-Wmissing-prototypes] no previous prototype for function 'GetMicroseconds'
xpcom/threads/CPUUsageWatcher.cpp:51:40 [-Wmissing-prototypes] no previous prototype for function 'GetProcessCPUStats'
xpcom/threads/CPUUsageWatcher.cpp:80:40 [-Wmissing-prototypes] no previous prototype for function 'GetGlobalCPUStats'
xpcom/threads/nsTimerImpl.cpp:196:21 [-Wmissing-prototypes] no previous prototype for function 'GetTimerFiringsLog'
Differential Revision: https://phabricator.services.mozilla.com/D23264
--HG--
extra : rebase_source : e03df033209e0a08fc263603e78bc16a09467f15
extra : source : 3beec9fbfdedf346fff85309029e7805717958ac
This change sets up nsLocalFileWin to mirror the behavior of
nsLocalFileUnix, which is all-around more reasonable than the behavior
nsLocalFileWin had before. We also, in passing, fix up some unnecessary
error-handling code at the end of Create().
Depends on D22360
Differential Revision: https://phabricator.services.mozilla.com/D22361
--HG--
extra : moz-landing-system : lando
We eventually want to make the common path just attempt file creation,
and only fall back to creating all the ancestor directories if the
initial attempt failed. To do that in a reasonable way, we'll need
re-usable code for the creation code, which is what this patch creates.
Depends on D22359
Differential Revision: https://phabricator.services.mozilla.com/D22360
--HG--
extra : moz-landing-system : lando
This patch tries to move them to `ContentParent` instead.
`ProcessPriorityManagerImpl::ObserveContentParentCreated` could not be moved
due to using `do_QueryInterface` to cast from a `nsISupports` down to the
`ContentParent` object. This could be fixed to remove the interfaces entirely,
but I left that for a follow-up.
Depends on D20549
Differential Revision: https://phabricator.services.mozilla.com/D20550
--HG--
extra : moz-landing-system : lando
This patch tries to move them to `ContentParent` instead.
`ProcessPriorityManagerImpl::ObserveContentParentCreated` could not be moved
due to using `do_QueryInterface` to cast from a `nsISupports` down to the
`ContentParent` object. This could be fixed to remove the interfaces entirely,
but I left that for a follow-up.
Depends on D20549
Differential Revision: https://phabricator.services.mozilla.com/D20550
--HG--
extra : moz-landing-system : lando
Give nsIStringStream separate SizeOfIncludingThisIfUnshared and SizeOfIncludingThisEvenIfShared methods. Use the former for memory reporting and the latter for JS engine memory accounting.
Differential Revision: https://phabricator.services.mozilla.com/D29336
Consequently, this removes:
- MOZ_LIBPRIO, which is now always enabled.
- non_msvc_compiler, which is now always true.
- The cl.py wrapper, since it's not used anymore.
- CL_INCLUDES_PREFIX, which was only used for the cl.py wrapper.
- NONASCII, which was only there to ensure CL_INCLUDES_PREFIX still
worked in non-ASCII cases.
This however keeps a large part of detecting and configuring for MSVC,
because we still do need it for at least headers, libraries, and midl.
Depends on D19614
Differential Revision: https://phabricator.services.mozilla.com/D19615
--HG--
extra : moz-landing-system : lando
Found when forcing a non-unified build of the Gecko Profiler:
- "nsError.h" needed to define `nsresult`.
- "nsStringFwd.h" needed to declare `nsAString` and `nsACString`.
Differential Revision: https://phabricator.services.mozilla.com/D18621
--HG--
extra : moz-landing-system : lando
The total size of an IPC inputStream message must be less than 1mb. When we
compose the message for the multiplex stream, each sub stream collaborates with
its own size, deciding if it's better to be a pipe stream (IPCRemoteStream) or
a full serialized one.
Differential Revision: https://phabricator.services.mozilla.com/D18543
--HG--
extra : moz-landing-system : lando
Before this set of patches, the decision of exposing the stream as a pipe was
centralized in IPCStreamUtils, based on the total expectation size of the IPC
message. This triggers issues when multiplex inputStreams contain something
that cannot be sent as a pipe (IPCBlobInputStream, for instance), or something
that it's better to do not set as a pipe (nsFileInputStream), together with
memory streams (nsStringInputStream), which could make the IPC message greater
then what accepted (1mb).
These patches move the "pipe vs non-pipe" choice into the single inputStream
implementation.
AsyncWaitRunnable holds a strong reference to its stream, and
NonBlockingAsyncInputStream holds a strong reference to the
runnable. The cycle gets broken in the RunAsyncWaitCallback() method
of the stream, but if the runnable is cancelled then we leak them
both. This patch fixes that by clearing the pointer to the stream when
the runnable is cancelled, breaking the cycle.
Differential Revision: https://phabricator.services.mozilla.com/D16248
--HG--
extra : moz-landing-system : lando
AsyncWaitRunnable holds a strong reference to its stream, and
NonBlockingAsyncInputStream holds a strong reference to the
runnable. The cycle gets broken in the RunAsyncWaitCallback() method
of the stream, but if the runnable is cancelled then we leak them
both. This patch fixes that by clearing the pointer to the stream when
the runnable is cancelled, breaking the cycle.
Differential Revision: https://phabricator.services.mozilla.com/D16248
--HG--
extra : moz-landing-system : lando
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13371
--HG--
extra : moz-landing-system : lando
* Changes the format of the blocklist from a list of characters to a list of
character ranges. Binary search still works, and it is easier to include
large ranges of characters in the blocklist.
* Moves logic for handling the blocklist to IDNBlocklistUtils.h/.cpp
* Changes NS_EscapeURL to take a function that determines if a character
is blocked. This way the type of the array doesn't matter.
Differential Revision: https://phabricator.services.mozilla.com/D12210
--HG--
extra : moz-landing-system : lando
In the current code there are 3 main issues:
1. nsFileStream is not really thread-safe. There is nothing to protect the
internal members and we see crashes.
2. nsPipeInputStream doesn't implement ::Seek() method and that caused issues
in devtools when a nsHttpChannel sends POST data using a pipe. In order to fix
this, bug 1494176 added a check in nsHttpChannel: if the stream doesn't
implement ::Seek(), let's clone it. This was an hack around nsPipeInputStream,
and it's bad.
3. When nsHttpChannel sends POST data using a file stream, nsFileStream does
I/O on main-thread because of the issue 2. Plus, ::Seek() is called on the
main-thread causing issue 1.
Note that nsPipeInputStream implements only ::Tell(), of the nsISeekableStream
methods. It doesn't implement ::Seek() and it doesn't implement ::SetEOF().
With this patch I want to fix point 2 and point 3 (and consequentially issue 1
- but we need a separate fix for it - follow up). The patch does:
1. it splits nsISeekableStream in 2 interfaces: nsITellableStream and
nsISeekableStream.
2. nsPipeInputStream implements only nsITellableStream. Doing this, we don't
need the ::Seek() check for point 2 in nsHttpChannel: a simple QI check is
enough.
3. Because we don't call ::Seek() in nsHttpChannel, nsFileStream doesn't do I/O
on the main-thread, and we don't crash doing so.
The sandbox blocks GetTempFileName's prior response, causing the system to end up searching a number of (inaccessible) folders to use as a replacement for the temp folder. This patch provides a path to a new folder on the command line for the plugin process. This new temp folder, specific to this plugin process instance, is then communicated to the system via the TEMP/TMP environment variables. This is similar to what is done for the content process but avoids nsDirectoryService, which doesn't exist in plugin processes.
Differential Revision: https://phabricator.services.mozilla.com/D7532
--HG--
extra : moz-landing-system : lando
The sandbox blocks GetTempFileName's prior response, causing the system to end up searching a number of (inaccessible) folders to use as a replacement for the temp folder. This patch provides a path to a new folder on the command line for the plugin process. This new temp folder, specific to this plugin process instance, is then communicated to the system via the TEMP/TMP environment variables. This is similar to what is done for the content process but avoids nsDirectoryService, which doesn't exist in plugin processes.
Differential Revision: https://phabricator.services.mozilla.com/D7532
--HG--
extra : moz-landing-system : lando
The sandbox blocks GetTempFileName's prior response, causing the system to end up searching a number of (inaccessible) folders to use as a replacement for the temp folder. This patch provides a path to a new folder on the command line for the plugin process. This new temp folder, specific to this plugin process instance, is then communicated to the system via the TEMP/TMP environment variables. This is similar to what is done for the content process but avoids nsDirectoryService, which doesn't exist in plugin processes.
Differential Revision: https://phabricator.services.mozilla.com/D7532
--HG--
extra : moz-landing-system : lando
Andrea Marchesini
ssengupta
Kagami Sascha Rosylight
Dorel Luca
Csoregi Natalia
Kershaw Chang
Aaron Klotz
Tom Tung
Simon Giesecke
Tom Tung
Valentin Gosu
Konstantin Morozov
Honza Bambas
Eric Rahm
Andreas Farre
Chris Peterson
Toshihito Kikuchi
Cosmin Sabou
Andrew McCreight
Ciure Andrei
Tuan
shindli
Nathan Froyd
Kristen Wright
Gijs Kruitbosch
Gabriele Svelto
Emilio Cobos Álvarez
Sylvestre Ledru
Matt Woodrow
Coroiu Cristina
Henri Sivonen
Boris Zbarsky
Barret Rennie
Masatoshi Kimura
Jonathan Kingston
arthur.iakab
Andreea Pavel
Dave Townsend
Alex Gaynor
David Major
Nathan Froyd
Jeff Walden
Razvan Maries
Ryan Hunt
Nika Layzell
Jon Coppeard
Mike Hommey
Gerald Squelart
Kris Maglione
Ehsan Akhgari
Jorg K
Tooru Fujisawa
Kirk Steuber
David Parks