Based on evidence from crash reports in Bug 1682589, there may be a bug where
IPDL intermittently calls `ActorDestroy()` twice on GamepadEventChannelParent,
leading to a crash.
This attempts to catch this behavior in Nightly (assuming that I'm correct and
it does exist). If not, I will have to find some other explanation for the
crash behavior from that bug.
Differential Revision: https://phabricator.services.mozilla.com/D100714
Bug 1657404 added assertions to catch errors in the platform-specific backends
for Gamepad. A bug in CocoaGamepad.cpp:StopGamepadMonitoring() causes one of
the new assertions to fire off.
As the solution to this is not easy, and a fix is required for Beta, the
easiest fix for now is to disable the assertion. In the long run, this needs
to be fixed.
Differential Revision: https://phabricator.services.mozilla.com/D99818
The most likely cause for the crashes seems like IPDL intermittently calling GamepadEventChannelParent::ActorDestroy() multiple times on the same object.
This adds a wrapper to stop that behavior (if it's the root cause), and also to fire off release assertions at several other potential causes.
Hopefully we see this crash signature disappear.
Differential Revision: https://phabricator.services.mozilla.com/D99720
This moves parts of IPCMessageUtils.h to two new header files and adapts
the include directives as necessary. The new header files are:
- EnumSerializer.h, which defines the templates for enum serializers
- IPCMessageUtilsSpecializations.h, which defines template specializations
of ParamTraits with extra dependencies (building upon both IPCMessageUtils.h
and EnumSerializer.h)
This should minimize the dependencies pulled in by every consumer of
IPCMessageUtils.h
Differential Revision: https://phabricator.services.mozilla.com/D94459
Starting with one of my earlier patches in Bug 1657404, FreeBSD started seeing
an error,
```
ld.lld: error: undefined hidden symbol:
mozilla::dom::SetGamepadLightIndicatorColor
```
We don't build this codepath as part of our regular Firefox testing, and so I
didn't see the issue.
Luckily, Jan Beich <jbeich@FreeBSD.org> noticed the issue and offered up this
patch. They unfortunately can't be given credit because they are protesting
our requirement for 2FA in Phabricator.
Differential Revision: https://phabricator.services.mozilla.com/D98973
Currently, the gamepad code uses a uint32_t as a handle and does some trickery
with it by trying to create a unique ID and adding an offset to it for VR code.
This can (and has) led to errors where the developer forgets to perform the
arithmetic and sends the wrong number to the wrong manager.
This change created a strongly-typed handle that remembers which service it
belongs to. This should eliminate such accidents.
Differential Revision: https://phabricator.services.mozilla.com/D96273
A substantial refactor of GamepadPlatformService:
1. Easier to understand lifetime
2. Correct usage of mutexes to protect shared state
3. Clear separation of "service owner" and "service user"
4. Simplify logic in some places
5. Better variable names
Differential Revision: https://phabricator.services.mozilla.com/D96664
Currently, the list of monitoring observers is stored in the
GamepadPlatformService. But it's possible for testing to start before an
event channel has been created, or to exist longer. That could result in the
GamepadPlatformManager being created-destroyed multiple times along with
this list.
Probably the simplest thing to do here is just have the list be its own
indepedent entity
Differential Revision: https://phabricator.services.mozilla.com/D96663
Currently, the AndroidGamepadManager uses a single function to both add and
remove gamepad service entries (Even though their functionality is different),
and it also uses a JNI callback to set the ID rather than simply returning it
This fixes both of those things.
Depends on D96270
Differential Revision: https://phabricator.services.mozilla.com/D96272
Currently, this promise is being created at one level of abstraction but
fulfilled at another. This will be important soon, as this promise is about
to become more complex.
Differential Revision: https://phabricator.services.mozilla.com/D96270
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Currently, the GamepadManager contains an nsTArray of event channels. However,
logically the code only ever allows this array to have either 0 or 1 entries.
This change replaces the nsTArray with a nullable pointer.
Differential Revision: https://phabricator.services.mozilla.com/D93594
This patch does:
- Use LSWriteOptimizer
- Remove SessionStorageService since it's unused.
- Move IPC from PContent to PBackground
(by SessionStorageManager{Child, Parent} and SessionStorageCache{Child, Parent}).
- Extract SessionStorageManagerBase and add PBackgroundSessionStorageManager.
- Expose a getter function to get a BackgroundParentManager for top context id
on the parent.
IPC
- Before this patch:
- Copy from parent while loading a document.
- Mark cache entry on the parent process as loaded by the child id.
- Update change on checkpoint.
- Unmark cache entry on the parent process as unloaded for the child id while
the parent actor is destorying.
- After this patch:
- Sync IPC load in the first SessionStorage operation.
- Update change on checkpoint
`BackgroundSessionStorageManager`'s lifecycle on the parent process.
- Create by `SessionStorageManagerParent` and register to the `sManagers`.
- Hold by `SessionStorageManagerParent` and `sManagers`.
- Remove from the `sManagers` while the corresponding `BrowsingContext` is
destructed (on the parent process).
Depends on D89341
Differential Revision: https://phabricator.services.mozilla.com/D89342
Since the test code will be waiting on a promise from the addGamepad message,
we can simply defer fulfilling the promise until monitoring starts if it
hasn't already.
Since every other message relies on the index given by the fulfilled promise,
it ensures that we won't get any simulated events until monitoring starts
Differential Revision: https://phabricator.services.mozilla.com/D86748
Each existing GamepadTestChannel needs to know when gamepad monitoring is
started or stopped so it knows whether it's safe to deliver messages.
Differential Revision: https://phabricator.services.mozilla.com/D86747
StartGamepadMonitoring() can end up in AddGamepad, and acquire the lock
again on the same thread, effectively dead-locking.
This is a regression from bug 1657404. Relevant stack:
(gdb) bt
#0 0x00007fd19bace801 in clock_nanosleep@GLIBC_2.2.5 () at /lib64/libc.so.6
#1 0x00007fd19bad4157 in nanosleep () at /lib64/libc.so.6
#2 0x00007fd19bad408e in sleep () at /lib64/libc.so.6
#3 0x00007fd195233e87 in ah_crap_handler(int) (signum=11) at /home/emilio/src/moz/gecko-4/toolkit/xre/nsSigHandlers.cpp:95
#4 0x00007fd1952165c4 in nsProfileLock::FatalSignalHandler(int, siginfo_t*, void*) (signo=11, info=0x7fd14abb9db0, context=0x7fd14abb9c80) at /home/emilio/src/moz/gecko-4/toolkit/profile/nsProfileLock.cpp:177
#5 0x00007fd1964973b2 in WasmTrapHandler(int, siginfo_t*, void*) (signum=11, info=<optimized out>, context=<optimized out>) at /home/emilio/src/moz/gecko-4/js/src/wasm/WasmSignalHandlers.cpp:978
#6 0x00007fd19bf3ca90 in <signal handler called> () at /lib64/libpthread.so.0
#7 mozilla::detail::MutexImpl::mutexLock() (this=<optimized out>) at /home/emilio/src/moz/gecko-4/mozglue/misc/Mutex_posix.cpp:118
#8 mozilla::detail::MutexImpl::lock() (this=<optimized out>) at /home/emilio/src/moz/gecko-4/mozglue/misc/Mutex_posix.cpp:142
#9 0x00007fd190cc795a in mozilla::OffTheBooksMutex::Lock() (this=0x7fd136649398) at /home/emilio/src/moz/gecko-4/xpcom/threads/BlockingResourceBase.cpp:318
#10 0x00007fd19326e65e in mozilla::detail::BaseAutoLock<mozilla::Mutex&>::BaseAutoLock(mozilla::Mutex&) (this=<optimized out>, aLock=...) at /home/emilio/src/moz/gecko-4/obj-debug-no-sccache/dist/include/mozilla/Mutex.h:159
#11 mozilla::dom::GamepadPlatformService::NotifyGamepadChange<mozilla::dom::GamepadAdded>(unsigned int, mozilla::dom::GamepadAdded const&) (this=0x7fd136649380, aIndex=1, aInfo=...)
at /home/emilio/src/moz/gecko-4/dom/gamepad/GamepadPlatformService.cpp:65
#12 0x00007fd193269178 in mozilla::dom::GamepadPlatformService::AddGamepad(char const*, mozilla::dom::GamepadMappingType, mozilla::dom::GamepadHand, unsigned int, unsigned int, unsigned int, unsigned int, unsigned int)
(this=0x7fd136649380, aID=<optimized out>, aMapping=mozilla::dom::GamepadMappingType::_empty, aHand=mozilla::dom::GamepadHand::_empty, aNumButtons=11, aNumAxes=8, aHaptics=0, aNumLightIndicator=0, aNumTouchEvents=0)
at /home/emilio/src/moz/gecko-4/dom/gamepad/GamepadPlatformService.cpp:96
#13 0x00007fd19326de4a in (anonymous namespace)::LinuxGamepadService::AddDevice(mozilla::udev_device*) (this=<optimized out>, dev=<optimized out>) at /home/emilio/src/moz/gecko-4/dom/gamepad/linux/LinuxGamepad.cpp:139
#14 0x00007fd19326a156 in (anonymous namespace)::LinuxGamepadService::ScanForDevices() (this=<optimized out>) at /home/emilio/src/moz/gecko-4/dom/gamepad/linux/LinuxGamepad.cpp:188
#15 (anonymous namespace)::LinuxGamepadService::Startup() (this=<optimized out>) at /home/emilio/src/moz/gecko-4/dom/gamepad/linux/LinuxGamepad.cpp:233
#16 mozilla::dom::StartGamepadMonitoring() () at /home/emilio/src/moz/gecko-4/dom/gamepad/linux/LinuxGamepad.cpp:334
#17 0x00007fd193269c6b in mozilla::dom::GamepadPlatformService::AddChannelParent(mozilla::dom::GamepadEventChannelParent*) (this=<optimized out>, aParent=<optimized out>)
at /home/emilio/src/moz/gecko-4/dom/gamepad/GamepadPlatformService.cpp:225
#18 0x00007fd19326d175 in mozilla::dom::GamepadEventChannelParent::Init() (this=0x7fd136e76a00) at /home/emilio/src/moz/gecko-4/dom/gamepad/ipc/GamepadEventChannelParent.cpp:50
#19 0x00007fd1913ba3a6 in mozilla::ipc::BackgroundParentImpl::RecvPGamepadEventChannelConstructor(mozilla::dom::PGamepadEventChannelParent*) (this=0x7fd13f888000, aActor=0x0)
at /home/emilio/src/moz/gecko-4/ipc/glue/BackgroundParentImpl.cpp:1109
#20 0x00007fd1917c7da1 in mozilla::ipc::PBackgroundParent::OnMessageReceived(IPC::Message const&) (this=0x7fd13f888000, msg__=...) at PBackgroundParent.cpp:4967
#21 0x00007fd1913ea71d in mozilla::ipc::MessageChannel::DispatchAsyncMessage(mozilla::ipc::ActorLifecycleProxy*, IPC::Message const&) (this=0x7fd13f8880f8, aProxy=0x7fd13ff48140, aMsg=...)
Differential Revision: https://phabricator.services.mozilla.com/D87967
Substitute and eliminate MaybeStopGamepadMonitoring(). The logic to do this
is so dependent on GamepadPlatformService that it should probably just be a
member.
Differential Revision: https://phabricator.services.mozilla.com/D86267
The starting/stopping of gamepad monitoring is probably a decision that
should be made at the level of the GamepadPlatformService, not in the IPC
actor. This is step 1, later I will expand some of these functions because
it makes the code easier to understand.
Differential Revision: https://phabricator.services.mozilla.com/D86266
Kartik Gautam
Chris Martin
Cosmin Sabou
Simon Giesecke
june wilde
Sylvestre Ledru
Butkovits Atila
Andi-Bogdan Postelnicu
Ricky Stewart
Bogdan Tara
Dorel Luca
Tom Tung
Razvan Maries
Emilio Cobos Álvarez
Daosheng Mu