This parameter isn't used by any implementation of onDispatchedEvent,
and keeping the parameter makes later refactorings in this bug more difficult.
MozReview-Commit-ID: 90VY2vYtwCW
This is similar like the previous patch, but for the 8-bit string variants.
Also, it changes assignment to Adopt() in GetCString() and GetDefaultCString()
to avoid an extra copy.
--HG--
extra : rebase_source : eba805c3a7b809d5ccd6e853b1c9010db9477667
It's just a complex wrapper for free(), or equivalent function. (In practice,
all the uses end up in free().)
--HG--
extra : rebase_source : 247ea8458aa57319bd1c8366115a9b4f39ed5a33
The test helper_touch_action_regions.html uses nsDOMWindowUtils to synthesize native input events and creates some runnables to trigger the test. It expects the runnables which synthesize native input events are processed first, then the runnables to continue the test, and finally the input events are forwarded from chrome process to content process. Enabling event prioritization may change the execution order.
Wraps those runnables to synthesize native input events as priority=input and dispatches those runnables to continue the test with priority=input to make sure the execution order is as expected.
MozReview-Commit-ID: 8hkaB1FRW9T
As well as the straightforward things, this lets us remove ReadSysFile and
WriteSysFile, which in turn lets us remove TestFileUtils.cpp.
--HG--
extra : rebase_source : fc90c05352e654ffc41009d8504a9c54f394fc3f
For some reason, I continuously ran into windows x64 specific failures when
trying to read this heap allocated data while the main thread was paused. I
don't know specifically how this happened, but I am able to avoid it by instead
directly allocating the buffer in a `mozilla::Array` in static storage, and
copying that data instead.
MozReview-Commit-ID: 473d6IpHlc4
Unfortunately during shutdown we can sometimes leak the runnable passed into
SystemGroup::Dispatch. It is leaked instead of being freed off main thread
because we sometimes are passing data which can only be freed on the main thread
safely to the main thread, and running the destructor on the wrong thread could
be really bad.
This is a really really gross workaround for that issue which helps to avoid the
XPCOM leak checker failures which were appearing on try.
MozReview-Commit-ID: GTfdxKnsTae
This involved a change to BackgroundHangMonitor, as it initialized sDisabled
incorrectly to false, instead of true, We need sDisabled initialized to true, as
we cannot assume that it is enabled until BackgroundHangMonitor::Startup() is
called.
MozReview-Commit-ID: 94slLTkNk3C
Currently LUL is a member of CorePS, meaning that it is guarded by the PSMutex.
This mutex is grabbed by the main thread at random points during the execution
of the program. This is unfortunate, as initializing LUL can take a long
time (>1s on my local machine), and we definitely don't want to be blocking the
main thread waiting for it.
In addition, in the BHR case, we used to be grabbing LUL when we got our first
hang, while both the PSMutex and the BHR monitor were being held. This meant
that the main thread could make no progress during LUL initializaion, as the BHR
monitor is grabbed by the main thread on every spin of the event loop.
This patch moves that initialization to be behind a completely separate lock,
and makes BHR initialize it on the background thread before acquiring the BHR
lock, meaning that no locks other than the one guarding LUL should be held
during its initialization.
MozReview-Commit-ID: GwNYQaEAqJ1
This involved a change to BackgroundHangMonitor, as it initialized sDisabled
incorrectly to false, instead of true, We need sDisabled initialized to true, as
we cannot assume that it is enabled until BackgroundHangMonitor::Startup() is
called.
MozReview-Commit-ID: 94slLTkNk3C
Currently LUL is a member of CorePS, meaning that it is guarded by the PSMutex.
This mutex is grabbed by the main thread at random points during the execution
of the program. This is unfortunate, as initializing LUL can take a long
time (>1s on my local machine), and we definitely don't want to be blocking the
main thread waiting for it.
In addition, in the BHR case, we used to be grabbing LUL when we got our first
hang, while both the PSMutex and the BHR monitor were being held. This meant
that the main thread could make no progress during LUL initializaion, as the BHR
monitor is grabbed by the main thread on every spin of the event loop.
This patch moves that initialization to be behind a completely separate lock,
and makes BHR initialize it on the background thread before acquiring the BHR
lock, meaning that no locks other than the one guarding LUL should be held
during its initialization.
MozReview-Commit-ID: GwNYQaEAqJ1
It's silly to use prmem.h within Firefox code given that in our configuration
its functions are just wrappers for malloc() et al. (Indeed, in some places we
mix PR_Malloc() with free(), or malloc() with PR_Free().)
This patch removes all uses, except for the places where we need to use
PR_Free() to free something allocated by another NSPR function; in those cases
I've added a comment explaining which function did the allocation.
--HG--
extra : rebase_source : 0f781bca68b5bf3c4c191e09e277dfc8becffa09
Eric Rahm
Nicholas Nethercote
Bill McCloskey
Sebastian Hengst
Carsten "Tomcat" Book
Markus Stange
Bevis Tseng
Nathan Froyd
Daniel Holbert
Sylvestre Ledru
Stone Shih
Andrew Osmond
Michael Layzell
Andrea Marchesini
Wes Kocher
Tom Ritter
Andreas Farre
Mats Palmgren