In bug 1614933 we changed the order in which the crash annotations are sent
from a crashed content process to the main process in order to prevent a
deadlock that would arise if the child process would block writing into the
pipe used to sent the annotations.
This unfortunately introduced a race that I had missed. Here's the sequence of
event when generating a crash in the child process:
1) The child process enters the exception handler
2) It requests a dump from the main process and wait
3) Once the dump is written, the child process wakes up again and writes out
the crash annotations
4) The child process quits
One the main process side it looks like this:
1) The crash generation thread receives a request to generate a dump
2) The dump is written out, the crash generation thread notifies the content
process that it can resume execution. During this step the finished
minidump is recorded in the `OnChildProcessDumpRequested()` callback.
3) The crash generation thread reads the crash annotations sent by the content
process and finalizes the crash report
4) The main process grabs the finalized crash report
The key issue here is that the main process in step 4 is woken up when the
content process dies. Notice how there's no synchronization between the crash
generation thread and the main thread in the main process: if the crash
generation thread takes too long reading the crash annotations the main thread
might see an incomplete or missing crash report; that's because the event that
wakes it up - the content process ending execution - can happen in parallel
with step 3.
This is an issue that was accidentally introduced in Windows by bug 1614933
but was already present in both Linux and macOS. It was just very unlikely to
happen.
This patch fixes the issue by splitting step 3 in the main process in two
different stages: in the main process we grab the generated minidump in
`OnChildProcessDumpRequested()`, Breakpad then unblocks the child process and
we read the annotations in `OnChildProcessDumpWritten()`. We grab the
`dumpMapLock` Mutex in the latter and release it in the former to ensure that
the main process will have to wait for the crash report to be finalized when
`TakeCrashedChildProcess()` is called. This might appear somewhat confusing
and even causes debug builds to spit a harmless warning (we don't want Mutexes
to be taken and released from different scopes if we can help it).
To implement the above behavior in Breakpad a new callback was introduced in
Windows, an existing one was used under macOS and an unused one was used under
Linux. This accounts for the different way in which minidumps are generated on
the three platforms.
Differential Revision: https://phabricator.services.mozilla.com/D74496
We already have an architecture to sync the storage access granted
result to all 3rd-party frames with the same tracking origin.
We use the same way to sync HasStorageAccess flag instead of relying
on permission manager update permissions to child processes.
Differential Revision: https://phabricator.services.mozilla.com/D73711
Before this patch, we only call StorageAccessGranted on windows that
triggers the storage heuristics. So even if we sync storage permission to the
other frames, their data will not be refreshed. For example, if a document
has a worker, we don't propagate the permission to the worker.
In this patch, we call ::StorageAccessGranted as long as we update
the window's storage permission.
Differential Revision: https://phabricator.services.mozilla.com/D74321
Before this patch, in non-fission mode, we cache storage access granted result
in the top-level window so we don't have to iterate all the browsing contexts
in the same tree while syncing the storage permission granted decision.
However, since we plan to rely on the current update mechanism to sync
mHasStorageAccess flag for different documents in the same tab (instead of using
the syncing mechanism of permission manager), we will eventually need to iterate
the browsing context tree to find all the documents to sync. Base on this,
we no longer have to maintain different method for fission and non-fission.
In this patch, we store the permission granted result in the inner
window instead of using permission key and store the key in the top-level
window.
Differential Revision: https://phabricator.services.mozilla.com/D73710
CookieBehavior should be the same for all the frames in the same tab,
we don't have to get its value for every browsing context in the same
browsing context tree.
Differential Revision: https://phabricator.services.mozilla.com/D73709
See https://bugzilla.mozilla.org/show_bug.cgi?id=932410#c2 for the
context for which this pseudo-element was added.
In the previous patch, I had to special-case range appearance because of
this pseudo-class, but that patch makes this pseudo-class completely
redundant, as now all form controls, themed and unthemed, display
outlines, unless the native theme displays a focus indicator on its own.
Remove the special case, and make ranges use outlines like everything
else rather than this bespoke pseudo-element.
Differential Revision: https://phabricator.services.mozilla.com/D74734
We already have an architecture to sync the storage access granted
result to all 3rd-party frames with the same tracking origin.
We use the same way to sync HasStorageAccess flag instead of relying
on permission manager update permissions to child processes.
Differential Revision: https://phabricator.services.mozilla.com/D73711
Before this patch, we only call StorageAccessGranted on windows that
triggers the storage heuristics. So even if we sync storage permission to the
other frames, their data will not be refreshed. For example, if a document
has a worker, we don't propagate the permission to the worker.
In this patch, we call ::StorageAccessGranted as long as we update
the window's storage permission.
Differential Revision: https://phabricator.services.mozilla.com/D74321
Before this patch, in non-fission mode, we cache storage access granted result
in the top-level window so we don't have to iterate all the browsing contexts
in the same tree while syncing the storage permission granted decision.
However, since we plan to rely on the current update mechanism to sync
mHasStorageAccess flag for different documents in the same tab (instead of using
the syncing mechanism of permission manager), we will eventually need to iterate
the browsing context tree to find all the documents to sync. Base on this,
we no longer have to maintain different method for fission and non-fission.
In this patch, we store the permission granted result in the inner
window instead of using permission key and store the key in the top-level
window.
Differential Revision: https://phabricator.services.mozilla.com/D73710
CookieBehavior should be the same for all the frames in the same tab,
we don't have to get its value for every browsing context in the same
browsing context tree.
Differential Revision: https://phabricator.services.mozilla.com/D73709
See https://bugzilla.mozilla.org/show_bug.cgi?id=932410#c2 for the
context for which this pseudo-element was added.
In the previous patch, I had to special-case range appearance because of
this pseudo-class, but that patch makes this pseudo-class completely
redundant, as now all form controls, themed and unthemed, display
outlines, unless the native theme displays a focus indicator on its own.
Remove the special case, and make ranges use outlines like everything
else rather than this bespoke pseudo-element.
Differential Revision: https://phabricator.services.mozilla.com/D74734
Gabriele Svelto
Tilden Windsor
Sam Foster
Matthew Noorenberghe
Jon Coppeard
Noemi Erli
kasun
Sebastian Streich
Sid Stamm
Luca Greco
Mihai Alexandru Michis
Csoregi Natalia
Dimi Lee
Frederik Braun
Emilio Cobos Álvarez
Dão Gottwald
Gijs Kruitbosch
Nicklas Boman
Brindusan Cristian
Narcis Beleuzu
Jared Wein
Robert Helmer