I'm going to be splitting DoCommonPrint so that the parts that run after the
static clone is created happen after a roundtrip to the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D83262
I specifically want to move this to happen before the static clone is made, in
preparation for splitting out the static clone logic from DoCommonPrint.
Differential Revision: https://phabricator.services.mozilla.com/D83260
We get a small amount of antialiasing-related "fuzz" on some platforms,
so those are noted in the corresponding .ini files.
Differential Revision: https://phabricator.services.mozilla.com/D82893
mozStorage used to read prefs on service init, because they could only be read
on the main-thread. When service init was moved earlier, it started trying
to read prefs too early, before the profile was set up, thus it ended up always
reading the default value.
This patch moves the only relevant pref to mirrored StaticPrefs that can be accessed
from different threads, and removes two preferences that apparently are not necessary
(they have been broken from a long time) for now.
In particular, providing a global synchronous setting is a footgun, each consumer should
decide about their synchronous needs, rather than abusing a dangerous "go fast" setting.
The page size is something we don't change from quite some time, and it's unlikely to be
used to run experiments in the wild before doing local measurements first, for which Try
builds are enough.
The remaining exclusiveLock pref is a bit controversial, because in general exclusive lock
is better for various reasons, and mostly it is necessary to use WAL on network shares.
Though developers may find it useful for debugging, and some third parties are doing
dangerous things (like copying over databases) to work around it, for which it's safer to
provide a less dangerous alternative.
Note exclusive lock only works on Unix-derived systems for now (no Windows implementation).
Finally, this introduces a fallback to exclusive lock, so that if a third party is using our
databases, so that we can't get an exclusive lock, we'll fallback to normal locking.
Differential Revision: https://phabricator.services.mozilla.com/D82717
DONTBUILD because this is a comment-only change.
Before this patch, these comments all mentioned "simple page sequence frame",
which is no longer a thing (it's been renamed to nsPageSequenceFrame). This
patch fixes that and corrects/clarifies these comments while we're at it.
(Note that these comments/classes may change a bit, as part of future patches
for the "pages-per-sheet" feature. This patch here is partly to get them to a
coherent starting state, for that work to build from.)
Differential Revision: https://phabricator.services.mozilla.com/D83233
We could make a new task for this, but `mozwebidlcodegen` depends on code in `mozbuild`, and vice-versa, so there doesn't really seem to be any meaningful advantage to that.
Differential Revision: https://phabricator.services.mozilla.com/D83187
It is possible that some threads fail/forget to unregister themselves, in which case a registered thread id could get recycled by a later thread, which was not allowed before this patch.
Note: The thread name cannot currently be changed. We record a special marker with the new name, so the frontend could process it to split the thread track at that point.
We also record a marker when profiler_unregister_thread is called from an already-unregistered thread, this could help find reg/unreg mismatches or nesting in Firefox threads.
Differential Revision: https://phabricator.services.mozilla.com/D83293
On Linux (including Android), it was assumed that a registered thread could always be suspended through `tgkill`.
However in some cases a thread may not be correctly unregistered, in which case this would trigger `MOZ_ASSERT` or wait forever in the following loop.
This will especially be needed when `profiler_{,un}register_thread()` are made less strict in the following patch.
Windows and Mac already handle suspension failures.
Differential Revision: https://phabricator.services.mozilla.com/D83292
We already have `value = source[key]` thanks to iteration; we should be
using `value` directly rather than re-doing `source[key]`.
Differential Revision: https://phabricator.services.mozilla.com/D83157
`CreateVisibleWhiteSpacesData()` is now called multiple times and maybe called
after the DOM tree is modified even though it's a bug. Therefore, we should
make it store first result and return its reference instead.
Differential Revision: https://phabricator.services.mozilla.com/D82701
