AtomList uses only PinnedStringId from BindingUtils, and there are no other
dependencies between BindingUtils and PinnedStringId, and BindingUtils is
complex to parse. Moving PinnedStringId to a separate header therefore seems
beneficial.
Differential Revision: https://phabricator.services.mozilla.com/D83769
Use the same shell-option + skip-if combo throughout private fields testing.
This skips testing of these in the browser (following the pattern established
for the test262 tests) however we have other pref-driven browser based tests,
which use an eval pattern to avoid failing if the pref isn't set.
Differential Revision: https://phabricator.services.mozilla.com/D84506
A useful function during development, it no longer maintains the required
invariants and can be replaced with real private fields now that parser support
is implemented
Differential Revision: https://phabricator.services.mozilla.com/D84513
This includes adding nsPrinterWin and nsPaperWin, so that we can retrieve
information from the printer device lazily.
Differential Revision: https://phabricator.services.mozilla.com/D84009
At some point it might be good to move all of the interaction with the native
Windows printer API into some sort of wrapper class, but this keeps it simple
for now.
Differential Revision: https://phabricator.services.mozilla.com/D84008
Pretty similar to the previous patch. To deal with register pressure on 32-bit x86,
the patch adds copyToScratchRegister to load an operand into a scratch register,
as alternative for useRegister.
Differential Revision: https://phabricator.services.mozilla.com/D84128
I had needed this before to export that header, and it's no longer
needed, but it seems useful anyways.
Depends on D81989
Differential Revision: https://phabricator.services.mozilla.com/D84252
The test is currently a permafail with fission enabled.
TestActor gets destroyed when navigating from about:blank to the test page and can be replaced by SpecialPowers calls.
Differential Revision: https://phabricator.services.mozilla.com/D84478
There is a race condition causing neither fullscreenchange nor fullscreenerror
to be dispatched for a requestFullscreen call in some cases, making the test
stuck. It can be triggered when the child process has exited fullscreen and
starts trying to request fullscreen again, but the parent process is still in
the process of exiting. This can happen when fullscreen is exited via erroneous
ways like detaching the fullscreen element from the document or navigating from
a fullscreen document.
This patch doesn't fix the underlying race condition, but instead changes the
test to avoid triggering it. The namespace checks in file_fullscreen-api removes
the fullscreen element to exit fullscreen, and repeats this process several
times, making it very likely to trigger the race condition, but there is no
reason it has to be done in this way, especially given that there is a test step
specifically checks this behavior.
We may still want to fix the underlying race condition at some point, but as it
can only be triggered via requesting fullscreen when exiting, it's unlikely to
be hit in normal use, so it's less important than making the test reliable.
Differential Revision: https://phabricator.services.mozilla.com/D84484
nsIProcessToolsService::kill is designed to kill without causing crash reports.
Let's make sure it does not cause crash reports.
Differential Revision: https://phabricator.services.mozilla.com/D82553
A small xpcom module implemented in Rust, designed to provide low-level tools to deal with processes
from JS. For the moment, the only notable feature is `kill()`, designed to be used from about:processes
Differential Revision: https://phabricator.services.mozilla.com/D82552
Warp code assumes index == initLength at the start of JSOp::InitArrayElem. The
VM implementation however didn't bump the initLength for hole values. This becomes
a problem when there's a spread loop and we enter Warp code there.
IonBuilder does not have this issue because initArrayElemTryFastPath checks for
MNewArray and in this case we have a loop phi so we don't use the fast path.
I added an assert to InitArrayElemOperation and cleaned it up a bit: restructure,
change the argument from HandleObject to HandleArrayObject etc.
Differential Revision: https://phabricator.services.mozilla.com/D84309
Simon Giesecke
Byron Campen [:bwc]
Scott
Matthew Gaudet
Bob Owen
Kirk Steuber
Ryan Kelly
Nika Layzell
James Graham
Jan de Mooij
Emilio Cobos Álvarez
Liang-Heng Chen
Julian Descottes
Nihanth Subramanya
Tooru Fujisawa
Alphan Chen
Xidorn Quan
Csoregi Natalia
Honza Bambas
David Teller
Neil Deakin
Bruno Bartolomasi
Jeff Gilbert
Mihai Alexandru Michis
Cosmin Sabou