Similar to the utility process in bug 1826393, we are seeing
crashes in the plugin process due to certain anti-virus apps such
as Symantec. This causes us to fail to load the Widevine plugin
with ERROR_MOD_NOT_FOUND.
This patch adds support to add blocklist entries for the GMPlugin
process type, and mirrors the entries added for the utility
process. It also adds a test case to verify the blocklist
integration.
Differential Revision: https://phabricator.services.mozilla.com/D176942
Similar to the utility process in bug 1826393, we are seeing
crashes in the plugin process due to certain anti-virus apps such
as Symantec. This causes us to fail to load the Widevine plugin
with ERROR_MOD_NOT_FOUND.
This patch adds support to add blocklist entries for the GMPlugin
process type, and mirrors the entries added for the utility
process. It also adds a test case to verify the blocklist
integration.
Differential Revision: https://phabricator.services.mozilla.com/D176942
- Remove nsWaylandDisplay thread specific objects as we don't need them.
- Use nsWaylandDisplay as non-referenced objects. There's only a global one.
- Create nsWaylandDisplay global object in nsAppRunner when Firefox starts. That ensures we create it in main thread.
- Remove mEventQueue, we don't need it.
- Remove mSyncCallback, it's unused.
Differential Revision: https://phabricator.services.mozilla.com/D176125
Someday I would like to figure out why this blocklist only works on ASCII strings and the freestanding one works on wide strings, but I'll leave that for another time I guess. This gets us closer to unifying the logic between the two blocklists, which is nice.
I ran the TestDllBlocklist* gtests locally while using the mozglue blocklist and the ones that are expected to pass do indeed pass.
Differential Revision: https://phabricator.services.mozilla.com/D176444
- Remove nsWaylandDisplay thread specific objects as we don't need them.
- Use nsWaylandDisplay as non-referenced objects. There's only a global one.
- Create nsWaylandDisplay global object in nsAppRunner when Firefox starts. That ensures we create it in main thread.
- Remove mEventQueue, we don't need it.
- Remove mSyncCallback, it's unused.
Differential Revision: https://phabricator.services.mozilla.com/D176125
- Migrate glxtest pid and pipe fd variables to static members of GfxInfo on Linux
- Implement GfxInfo::FireGLXTestProcess() to run glxtest process.
Differential Revision: https://phabricator.services.mozilla.com/D175867
glxtest is run later when Firefox already spawns threads. Recently glxtest runs in forked process
which doesn't work correctly in multi-thread environment, so we need to move glxtest to different binary file
and launch it as stand alone code.
Differential Revision: https://phabricator.services.mozilla.com/D173486
Right now we fire glxtest on every Firefox start, even if we going to update, restart or ping running remote instance.
When we're running on system with broken/unstable gfx drivers (drivers/glx freezes or crashes) every such action is delayed or coredumps are generated on systems.
In this patch we launch glx test proces later if we know we need it.
Depends on D168650
Differential Revision: https://phabricator.services.mozilla.com/D168651
glxtest is run later when Firefox already spawns threads. Recently glxtest runs in forked process
which doesn't work correctly in multi-thread environment, so we need to move glxtest to different binary file
and launch it as stand alone code.
Differential Revision: https://phabricator.services.mozilla.com/D173486
Right now we fire glxtest on every Firefox start, even if we going to update, restart or ping running remote instance.
When we're running on system with broken/unstable gfx drivers (drivers/glx freezes or crashes) every such action is delayed or coredumps are generated on systems.
In this patch we launch glx test proces later if we know we need it.
Depends on D168650
Differential Revision: https://phabricator.services.mozilla.com/D168651
glxtest is run later when Firefox already spawns threads. Recently glxtest runs in forked process
which doesn't work correctly in multi-thread environment, so we need to move glxtest to different binary file
and launch it as stand alone code.
Differential Revision: https://phabricator.services.mozilla.com/D173486
Right now we fire glxtest on every Firefox start, even if we going to update, restart or ping running remote instance.
When we're running on system with broken/unstable gfx drivers (drivers/glx freezes or crashes) every such action is delayed or coredumps are generated on systems.
In this patch we launch glx test proces later if we know we need it.
Depends on D168650
Differential Revision: https://phabricator.services.mozilla.com/D168651
Andrew Osmond
Norisz Fay
Tom Ritter
stransky
Noemi Erli
Valentin Gosu
Mike Hommey
Greg Stoll
Alexandre Lissy
Cristina Horotan
serge-sans-paille
Peter Van der Beken
Andi-Bogdan Postelnicu
Stanca Serban
Cosmin Sabou
Narcis Beleuzu
Yannis Juglaret