We hook several file APIs to record I/O performance data. Since TLS is not
allocated in ntdll's loader worker thread, however, if someone does a file
operation, we hit read AV because `WinIOAutoObservation` uses `nsString` and
a thread local variable.
Currently we can see this crash happens only when a DLL rule of AppLocker is
defined, but theoretically this can happen when any module loaded in a worker
thread does file operation in its entrypoint.
The proposed fix is to skip `WinIOAutoObservation` if TLS is not available.
Differential Revision: https://phabricator.services.mozilla.com/D113032
When restarting, we set the XRE_PROFILE_PATH env var. This normally would
prevent us from showing the skeleton UI. This patch just adds another env
var to indicate that we are restarting so the skeleton UI can know it's
safe to display.
Differential Revision: https://phabricator.services.mozilla.com/D111884
Eliminates the NPAPI plugin process type from the GeckoChildProcess enum as part of NPAPI removal. In order to avoid altering enum values when updating the process list, the GECKO_PROCESS_TYPE macro has been updated to include the desired enum value. We want to resist altering the values as they need to be consistent e.g. in telemetry reports.
We also remove plugins from adjacent spots that need to maintain consistency with GeckoChildProcess -- most notably the nsICrashService.
Differential Revision: https://phabricator.services.mozilla.com/D108689
Eliminates the NPAPI plugin process type from the GeckoChildProcess enum as part of NPAPI removal. In order to avoid altering enum values when updating the process list, the GECKO_PROCESS_TYPE macro has been updated to include the desired enum value. We want to resist altering the values as they need to be consistent e.g. in telemetry reports.
We also remove plugins from adjacent spots that need to maintain consistency with GeckoChildProcess -- most notably the nsICrashService.
Differential Revision: https://phabricator.services.mozilla.com/D108689
When `--backgroundtask TASK` invocations exit, they try to remove
their temporary profile directory. This mostly works, except there
are some very late writes to the profile directory including
`Telemetry.ShutdownTime.txt` and the `security_state` directory. This
commit accommodates by moving the profile directory removal even
later. It might be possible to instead avoid these very late writes,
but that is hard in general, and is more likely to depend on the exact
code invoked by the background task itself.
Differential Revision: https://phabricator.services.mozilla.com/D110472
This patch uses the low memory resource notification facility to detect
scenarios where physical memory is running low without polling. This is a
significant change compared to the previous behavior which measured both
available virtual memory (only on 32-bit builds) and available commit space.
Since we're not trying to avoid OOMs anymore we don't save memory reports
anymore when hitting a low-memory condition.
Differential Revision: https://phabricator.services.mozilla.com/D110354
Also make CompactPair<A, B> a literal type if A and B are literal types,
and add MaybeStorageBase that ought to be used as a basis of MaybeStorage
in a follow-up patch.
Differential Revision: https://phabricator.services.mozilla.com/D55930
Firstly we need to find a usable ScriptLoader for code in the content script sandbox,
for that we use the normal ScriptLoader associated with DOMWindow wrapped by the sandbox.
Secondly we need to execute the module in the global of the sandbox instead of the
"ScriptGlobal" the ScriptLoader is actually associated with. The main
behavior change here comes from using xpc::NativeGlobal in HostImportModuleDynamically
and passing that global around inside ScriptFetchOptions.
To ensure that content-scripts and the webpage don't share imported modules,
the module map (mFetchingModules and mFetchedModules) now uses a complex key
of <URI, Global>. The Global is a nullptr for normal imports from a webpage.
Differential Revision: https://phabricator.services.mozilla.com/D107076
While NS_ERROR_FILE_CORRUPTED already exists, it indicates most of the times more a parsing problem of a given file format.
But Windows ERROR_FILE_CORRUPTED signals a malfunctioning or corrupted file system at OS level, thus we translate it to the new
NS_ERROR_FILE_FS_CORRUPTED.
There seems to be no suitable errno under POSIX to map here.
Differential Revision: https://phabricator.services.mozilla.com/D108793
A long standing issue is that MOZ_ASSERT and related don't print stack
traces in debug builds when they're directly or indirectly emitted from
non-libxul code. Moving WalkTheStack to mozglue alleviates the problem.
It's also not printing stack traces when emitted from C code (and for
some C third party libraries, we do redirect assert to MOZ_ASSERT),
which we solve by making the corresponding API available without C++
(which WalkTheStack being a static method of the nsTraceRefCnt class
didn't allow, or the use of a closure on Android).
This requires some adjustements to headers that indirectly assume that
Assertions.h includes ErrorList.h through nsError.h through nscore.h
through nsTraceRefcnt.h.
We also remove TestStackCrawl.cpp because it hasn't been built since
bug 158528, 19 years ago.
Differential Revision: https://phabricator.services.mozilla.com/D108913
Firstly we need to find a usable ScriptLoader for code in the content script sandbox,
for that we use the normal ScriptLoader associated with DOMWindow wrapped by the sandbox.
Secondly we need to execute the module in the global of the sandbox instead of the
"ScriptGlobal" the ScriptLoader is actually associated with. The main
behavior change here comes from using xpc::NativeGlobal in HostImportModuleDynamically
and passing that global around inside ScriptFetchOptions.
To ensure that content-scripts and the webpage don't share imported modules,
the module map (mFetchingModules and mFetchedModules) now uses a complex key
of <URI, Global>. The Global is a nullptr for normal imports from a webpage.
Differential Revision: https://phabricator.services.mozilla.com/D107076
Firstly we need to find a usable ScriptLoader for code in the content script sandbox,
for that we use the normal ScriptLoader associated with DOMWindow wrapped by the sandbox.
Secondly we need to execute the module in the global of the sandbox instead of the
"ScriptGlobal" the ScriptLoader is actually associated with. The main
behavior change here comes from using xpc::NativeGlobal in HostImportModuleDynamically
and passing that global around inside ScriptFetchOptions.
To ensure that content-scripts and the webpage don't share imported modules,
the module map (mFetchingModules and mFetchedModules) now uses a complex key
of <URI, Global>. The Global is a nullptr for normal imports from a webpage.
Differential Revision: https://phabricator.services.mozilla.com/D107076
The SpinEventLoopUntilOrShutdown is interrupted in the main process only at stage "xpcom-shutdown", which is too late. In a content process instead we interrupt it early enough, at "content-child-will-shutdown".
This patch removes the current observer logic in nsThreadManager in favor of a current shutdown phase state machinery in AppShutdown and renames SpinEventLoopUntilOrShutdown to SpinEventLoopUntilOrQuit. It also ensures that SpinEventLoopUntilOrQuit breaks early (at "quit-application" in the main process).
For a further possible cleanup around shutdown state in child and parent process please refer to bug 1697745.
We have no automated test for this edge case, but we have diagnostic telemetry that will tell us if it helps.
Differential Revision: https://phabricator.services.mozilla.com/D107619
Currently, printf_stderr doesn't show up when running with ./mach run.
This is because we run with -attach-console and that redirects stderr
to a different file descriptor using freopen in UseParentConsole.
The change from just using stderr directly happened in bug 340443 and was done
to avoid some linking issues. That problem doesn't seem to apply anymore so you'd
expect we'd be able to go back to the straightforward implemention that works even
if stderr has been redirected. Unfortunately, Windows takes not buffering
stderr very seriously and fprintf will write out the results character
by character. This can cause log output lines to be intermixed which
breaks log parsing in CI. We keep using fdopen to create a new FILE*
that's buffered but instead of hard coding fd 2, we get the actual fd
that corresponds to stderr using fileno.
The mozglue implementation was cargo culted from xpcom, so we update it
as well.
Differential Revision: https://phabricator.services.mozilla.com/D98550
This is follow-up to Bug 1687549, which added the `maxsize` flag.
That works well, but it's hard to distinguish separate logging
sessions. This makes it a little easier.
This calls through to a slightly modified `Print`, leveraging the
concurrency correctness of that implementation. Doing so doesn't
allow great visual distinction, but it's enough.
This produces output like:
```
$ firefox --backgroundtask success --MOZ_LOG prependheader
***
[(null) 1937604: Main Thread]: I/Logger Opening log
*** You are running in background task mode. ***
...
```
and
```
$ firefox --backgroundtask success --MOZ_LOG prependheader,raw
***
Opening log
*** You are running in background task mode. ***
...
```
Differential Revision: https://phabricator.services.mozilla.com/D106224
And fix existing users of course.
The frame loader one is the only one slightly scary (but if it causes
trouble we could make nsObjectLoadingContent::Unlink a no-op).
Differential Revision: https://phabricator.services.mozilla.com/D107269
Note that this patch only transforms the use of the nsDataHashtable type alias
to a directly equivalent use of nsTHashMap. It does not change the specification
of the hash key type to make use of the key class deduction that nsTHashMap
allows for in some cases. That can be done in a separate step, but requires more
attention.
Differential Revision: https://phabricator.services.mozilla.com/D106008
For making delete handlers simpler, and set better target ranges to the
corresponding `beforeinput` event, we should ignore non-editable ranges
before handling deletion.
This patch makes editor stop handling deleteion when a range crosses editing
host boundaries. In this case, Gecko has done nothing, but fired
`beforeinput` event. Note that Blink deletes editable contents in the range
**until** it meets first non-editable content, but I don't think this is
a good behavior because it makes things complicated. Therefore, I filed
a spec issue: https://github.com/w3c/editing/issues/283
On the other hand, this behavior change causes different behavior in
https://searchfox.org/mozilla-central/source/editor/libeditor/crashtests/1345015.html
It tries to insert paragraph into `<html>` element, but our editor currently
does not support it. Therefore, it hits `MOZ_ASSERT`. Therefore, this patch
added a new check into `HTMLEditor::InsertParagraphSeparatorAsSubAction()`.
Differential Revision: https://phabricator.services.mozilla.com/D107588
Toshihito Kikuchi
Steve Fink
Valentin Gosu
Cosmin Sabou
Narcis Beleuzu
Gerald Squelart
Mike Hommey
Doug Thayer
Butkovits Atila
Jens Stutte
smolnar
Emma Malysz
Jon Coppeard
David Parks
Csoregi Natalia
Nick Alexander
Simon Giesecke
Tom Schuster
Bogdan Tara
Jeff Muizelaar
Peter Van der Beken
Anny Gakhokidze
Emilio Cobos Álvarez
nchevobbe
Masayuki Nakano
Jan de Mooij