This patch adds a new field to the structures that WER reads from a
crashed process. This field contains a pointer to the global variable
that records the size of the last failed annotation.
When WER intercepts a crash it will use this address to read the
variable. If it's not zero it will add the corresponding annotation
to the crash report.
Depends on D116449
Differential Revision: https://phabricator.services.mozilla.com/D116450
Since this added the new flag to the crash ping I also took the time to update
the crash ping documentation with all the flags that have been added and
removed over the last few versions of Firefox.
Depends on D115380
Differential Revision: https://phabricator.services.mozilla.com/D116017
This also notifies the main process after the minidump has been generated.
I refactored the code a bit so the patch is probably larger than it should be
but the code should be a bit more readable overall.
With this change the minidump generation flow works like this:
- When the callback gets invoked in the WER process we read the structure that
is stored in every process' to figure out if it's the main process or a child
one. This is done by reading said process' memory, the pointer has been
passed to the runtime exception module when it was registered.
- If the main process crashed everything works like it used to.
- If it was a child process then we first capture a minidump of it.
- Then we read the structure representing it in the main process:
WindowsErrorReportingData. The address of this structure was passed into the
child process' command-line so we need to parse that first, then we read it
from the main process memory.
- We fill the structure and write it back into the main process memory.
- At this point if everything went fine we create a new thread in the main
process just to execute the WerNotifyProc function that will inform the main
process to the presence of the new minidump.
There's one important tidbit that's worth keeping in mind: the synchronization
between the main process and the WER process is implicit. The
WindowsErrorReportingData structure in the main process is kept alive until the
child process dies, the main process will destroy it only after that point. As
long as we're in the runtime exception module the crashed process is kept alive
so this will prevent the main process from touching that structure.
We explicitly terminate the crashed process **after** we're done with the
structure so nothing bad could happen... unless someone makes a change to
Gecko that breaks the previous assumption.
Another important thing to keep in mind: we wait for the newly created thread
to inform the main process but only for 5 seconds. We don't want to wait
indefinitely because the function that we're calling is taking a lock and if
it blocks for some reason WER will get stuck waiting for it, so it will never
kill the crashed process which in turn will prevent the main process from
moving ahead. In principle this should never happen but better be safe than
sorry.
Depends on D115379
Differential Revision: https://phabricator.services.mozilla.com/D115380
This patch sets up a few different things that will be used by the WER runtime
exception module when it needs to notify the main process of a child process
crash.
For every child process we allocate a structure in the main process called
WindowsErrorReportingData that contains three things:
- The address of the function used to notify the main process that there's a
pending minidump for a given child process
- The PID of said child process
- The name of the minidump that has been generated
The first field is filled up by the main process and will be read by the WER
process when running the runtime exception module, the second and third fields
on the other hand start empty and will be written into by the runtime exception
module after it has generated a minidump.
I know this sounds scary. It is. But bear with me please.
When we register the runtime exception module we can pass it a single
pointer-sized parameter but we need to pass it at least another pointer that
includes data coming from the child process itself (this one is called
InProcessWindowsErrorReportingData). This data currently includes only the
process type but will also include certain annotations in the future
(e.g. bug 1711418). So here's what we do: we store a pointer to the parent
data structure in the child process command-line (cringe) and we read it
from the runtime exception module by reading the crashed process command-line
arguments and parsing them (double-cringe).
Armed with this information the WER runtime exception module can populate
the info for the generated minidump and then push it into the main process
by calling CreateRemoteThread() (which creates a new thread in the main
process, triple-cringe at this point).
Differential Revision: https://phabricator.services.mozilla.com/D115379
Otherwise we assert due to the styles being different from the cached
ones, but it doesn't matter as these don't influence Gecko scrollbars.
Differential Revision: https://phabricator.services.mozilla.com/D117147
This matches what macOS is doing in bug 1715145, and improves the
situation in the cases the user chooses a light Firefox theme, but a
dark GTK theme, or vice versa.
The nice thing of doing it globally is that we don't need to teach the
GTK code to paint with different color schemes in different windows,
which would be massively annoying.
This is expected to have an slight performance cost on startup for
light-theme users (as we need to read the dark gtk theme colors), but
it's hopefully ok.
Depends on D117227
Differential Revision: https://phabricator.services.mozilla.com/D117228
The HTML spec looks at the "list of available images" before performing
lazy-loading. So if any test before loads these sources then the image
may actually load, against the test expectations.
Differential Revision: https://phabricator.services.mozilla.com/D117411
The problem here is that when `nsHostResolver::FlushCache` is called, a record is not removed from `mRecordDB` because `LoadNative()` returns true. The reason of this is that the record is in the low queue and this record is not being handled immediately. As a result of this, the record would stay in the low queue for a long time.
Depends on D117284
Differential Revision: https://phabricator.services.mozilla.com/D117285
- Added a new set of xpcshell-tests in toolkit/components/extensions/test/xpcshell/webidl-api
for unit tests related to the WebIDL bindings API request forwarding
Depends on D99886
Differential Revision: https://phabricator.services.mozilla.com/D99887
ExtensionMockAPI is a fake WebExtensions API, locked behind a pref and
used in unit tests related to the API requests handling and WebExtensionStub
methods without relying on a specific WebExtension API.
Depends on D84687
Differential Revision: https://phabricator.services.mozilla.com/D99886
The ExtensionPort represents the webidl definitions of the runtime.Port WebExtensions API object.
A webidl dictionary will represent the serializable definition of the port properties, sent from
the API request handler to provide all the internal properties needed to create an instance
of the ExtensionPort webidl interface on the worker thread (which will be returned to the
extension code as the return value of the runtime.connect/connectNative methods and as a
parameter of the calls to the runtime.onConnect API event listeners).
Depends on D84684
Differential Revision: https://phabricator.services.mozilla.com/D84685
An ExtensionEventListener xpcom interface that wraps an API event callback
and included in the API requests forwarded to the API request handler.
The ExtensionEventListener xpcom interface provides a method to forward
to the worker thread the calls to the wrapped API event callpack originated
from the WebExtensions framework running on the main thread.
Depends on D75311
Differential Revision: https://phabricator.services.mozilla.com/D80609
New XPCOM idl interfaces to define the components used to:
- represent an API request (call to API methods, add/remove API event listener,
get the value of an API property getter)
- define the API request handler defined by privileged JS code running on the
main thread
New ExtensionAPIBase shared stub methods and helper methods to create and forward
the API requests from the worker to the main thread and translate the results
got from the API request handler in the value to return or resolve (or the errors
to be raised) to the extension code running on the worker thread.
Depends on D80604
Differential Revision: https://phabricator.services.mozilla.com/D75311
WebIDL interface and c++ class to be used by all WebExtension API webidl bindings
to expose the expected WebExtensions API events (e.g. browser.tabs.onUpdated etc.)
Depends on D84682
Differential Revision: https://phabricator.services.mozilla.com/D80604
An ExtensionAPIBase class which provides a collection of shared stub methods and
shared helpers and used as a base class for the actual WebExtensions API webidl classes.
Depends on D84681
Differential Revision: https://phabricator.services.mozilla.com/D84682
Define a new WebExtensionStub extended attribute in the WebIDL generator
to be used in the WebExtensions API WebIDL definitions.
Depends on D70372
Differential Revision: https://phabricator.services.mozilla.com/D84681
- Extension API WebIDL to be part of a new dom/extensions-webidl directory
(and all webidl in this directory associated with WebExtensions::General
bugzilla component)
- Extension API C++ implementation in a new toolkit/components/extensions/webidl-api
directory
- Lock Extensions API WebIDL bindings provided to extensions workers global on:
- the preference "extensions.backgroundServiceWorker.enabled" being set to true
- checking explicitly that the worker is an extension service worker declared
in the extension manifest.json file.
- Changes to WorkerPrivate, WorkerScope.h/.cpp to expose the WebIDL
bindings to the extension service workers (if the service worker has been
detected as the background service worker specified in the manifest),
plus small changes to RemoteWorkerChild.cpp to detect if the worker
is the background service worker (and mark it as so in the WorkerPrivate
instance associated to it)
Differential Revision: https://phabricator.services.mozilla.com/D70372
This results in lots of new WPT test passes.
There were also a couple of WPT tests that turned out to be broken;
tab-size-inline-001 and -002 had errors in their reference files such
that they'd never pass anywhere. So those are fixed here.
Depends on D117331
Differential Revision: https://phabricator.services.mozilla.com/D117332
This patch implements the parent process' part of NavigationPreload API.
After receiving the IPC, using the corresponding ServiceWorkerRegistrationProxy to send data to the main thread, then saving the NavigationPreload data on ServiceWorkerRegistrationInfo.
Depends on D116916
Differential Revision: https://phabricator.services.mozilla.com/D116917
This patch implements the IPC for NavigationPreload APIs.
The IPC methods are created on PServiceWorkerRegistration.
Depends on D116914
Differential Revision: https://phabricator.services.mozilla.com/D116916
Julian Descottes
Gabriele Svelto
Emilio Cobos Álvarez
Christoph Kerschbaumer
Marian-Vasile Laza
Kershaw Chang
Peter Van der Beken
Luca Greco
Jonathan Kew
Kai Engert
Jens Stutte
Tooru Fujisawa
Tim Huang
Nicolas Silva
Jeremy Nuttall
Mark Banner
Eden Chuang