This is yet another attempt to get reasonable-looking thumbnails in the
taskbar for restored windows after they get resized. This time we're
actually signaling to invalidate the current thumbnail after the window
gets restored, which I'm hopeful will fix the issue.
As usual, this all works on my machine with a dev build :-/
Differential Revision: https://phabricator.services.mozilla.com/D269422
This allows us to shut down the IAudioSessionManager after Cubeb has stopped,
so there shouldn't be STA apartment deadlock issues with it.
IAudioSessionManager's shutdown always requires the STA. This patch eliminates
MTA threads involvement at shutdown, which was previously needed for thread
safety. We keep other operations on MTA (background) threads, for performance.
This also removes a lot of unused functionality. AudioSession hasn't been
needed outside of the parent process since audio remoting landed.
Differential Revision: https://phabricator.services.mozilla.com/D251773
This allows us to shut down the IAudioSessionManager after Cubeb has stopped,
so there shouldn't be STA apartment deadlock issues with it.
IAudioSessionManager's shutdown always requires the STA. This patch eliminates
MTA threads involvement at shutdown, which was previously needed for thread
safety. We keep other operations on MTA (background) threads, for performance.
This also removes a lot of unused functionality. AudioSession hasn't been
needed outside of the parent process since audio remoting landed.
Differential Revision: https://phabricator.services.mozilla.com/D251773
Native event processing requires the creation of an event window,
which isn't possible under win32k lockdown, resulting in a MOZ_CRASH.
This change adds an assertion about the state of win32k lockdown to
differentiate crashes that would occur because of win32k lockdown from
crashes that would occur for other reasons. This only affects the
GPU process (through nsAppShell::PrecacheEventWindow) because, since
bug 1950112, nsAppShell::Init now avoids native event processing if
win32k is unavailable.
Differential Revision: https://phabricator.services.mozilla.com/D239987
Remove the MouseScrollHandler::ProcessNative{MouseWheel,Scroll}Message()
functions as dead code.
Similarly, remove the now-unused mIsWaitingInternalMessage flag, its
getter, and all associated conditionals.
No functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D236592
Remove the MouseScrollHandler::ProcessNative{MouseWheel,Scroll}Message()
functions as dead code.
Similarly, remove the now-unused mIsWaitingInternalMessage flag, its
getter, and all associated conditionals.
No functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D236592
Remove the MouseScrollHandler::ProcessNative{MouseWheel,Scroll}Message()
functions as dead code.
Similarly, remove the now-unused mIsWaitingInternalMessage flag, its
getter, and all associated conditionals.
No functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D236592
This patch ensures that we call CreateWindow before lowering the
GPU sandbox, hoping that this will prevent ERROR_ACCESS_DENIED during
the call to CreateWindow.
Differential Revision: https://phabricator.services.mozilla.com/D226282
This patch makes the single-step data collection code that we
implemented for bug 1571516 reusable, while preserving its behavior.
No functional changes, except for a slight reordering of the
error-result enum.
We define a generic CollectSingleStepData function that embeds the
magic for starting to trigger single step exceptions and for acting upon
them.
We define a more specialized CollectModuleSingleStepData function which
can be reused if the purpose of single step data collection is to
monitor what paths are taken within a specific module. It stores the
collected data in stack, so that it can be accessed from crash reports.
This code is considered unstable and thus only available in Nightly and
early Beta and only used on paths that are known to crash already.
Differential Revision: https://phabricator.services.mozilla.com/D211195
In the fx codebase, we tend to use __attribute__((naked)) for plain
assembly functions with a C interface. Instrumenting these functions can
mess up this assembly, so we conservatively also want to prevent
instrumentation.
Differential Revision: https://phabricator.services.mozilla.com/D196154
This patch makes the single-step data collection code that we
implemented for bug 1571516 reusable, while preserving its behavior.
We define a generic CollectSingleStepData function that embeds the
magic for starting to trigger single step exceptions and for acting upon
them.
We define a more specialized CollectModuleSingleStepData function which
can be reused if the purpose of single step data collection is to
monitor what paths are taken within a specific module. It stores the
collected data in stack, so that it can be accessed from crash reports.
This code is considered unstable and thus only available in Nightly and
early Beta and only used on paths that are known to crash already.
Differential Revision: https://phabricator.services.mozilla.com/D194203
This patch runs RegisterClassW and CreateWindowW a second time when they
fail, so that we can trace their execution and collect single-step data.
We collect RIP values as we step through user32 code. We also collect
changes in the error state while in user32. We store the collected data
in the stack so that it appears in the crash dumps.
Because this patch only affects behavior after a first failure (which
would normally lead to an immediate crash), it does not alter behavior
for non-crashing users.
Differential Revision: https://phabricator.services.mozilla.com/D189240
Improve logging around InitHiddenWindow():
- Normalize WinErrorState.
- Simplify access to the OS-cached last-NTSTATUS value.
- Store and clear the last error-state more frequently.
- When ::CreateWindowW() fails, keep enough information to determine
whether a call to ::RegisterClassW() was attempted.
- To rule out user atom table exhaustion, check the capacity and
availability of the user atom table after a call that might have
created a user atom fails.
- To rule out early return from our WndProc, when
::RegisterWindowMessageW() fails, leave the extant value of
sAppShellGeckoMsgId in place.
Differential Revision: https://phabricator.services.mozilla.com/D188307
Per https://bugzilla.mozilla.org/show_bug.cgi?id=1571516#c24, we don't
currently store diagnostic data like the value of `::GetLastError()` in
stack dumps. However, we do store the current stack, and that's enough
to be usable.
Store some additional (critical?) diagnostic information in local
variables on the stack... and disable optimizations for that function,
to ensure that those variables actually exist in the stack-dump.
Arguably, no functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D186988
Pull the failing section of code out into its own function, for the sake
of clarity of later diffs.
No functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D186987
Per https://bugzilla.mozilla.org/show_bug.cgi?id=1571516#c24, we don't
currently store diagnostic data like the value of `::GetLastError()` in
stack dumps. However, we do store the current stack, and that's enough
to be usable.
Store some additional (critical?) diagnostic information in local
variables on the stack... and disable optimizations for that function,
to ensure that those variables actually exist in the stack-dump.
Arguably, no functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D186988
Pull the failing section of code out into its own function, for the sake
of clarity of later diffs.
No functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D186987
The window message we previously hooked no longer gets sent and the associated shared memory no longer seems to be created either.
Also, we don't seem to be notified about the load of UIAutomationCore.dll until after it has already instantiated a11y, which is obviously too late for us to hook anything.
Instead, we block UIA instantiation via LazyInstantiator, just as we do for MSAA/IA2:
1. Refactor CompatibilityUIA so that rather than being called by a hook, it simply allows the caller to query the process ids of any UIA clients.
2. CompatibilityUIA now searches handles in our process for named pipes created by UIA for communication with the remote process and then uses GetNamedPipeServerProcessId to get the process id on the other end of each pipe.
3. Refactor LazyInstantiator so that it first tries to get the MSAA/IA2 client process id, then calls CompatibilityUIA to get any UIA client process ids.
4. LazyInstantiator now handles setting the instantiator and blocking of clients for UIA as well as MSAA/IA2 using the same code.
5. Because UIA client detection can be expensive if clients repeatedly query us, cache the result. Reset that cache only when one of our windows comes to the foreground.
Differential Revision: https://phabricator.services.mozilla.com/D181958
The window message we previously hooked no longer gets sent and the associated shared memory no longer seems to be created either.
Also, we don't seem to be notified about the load of UIAutomationCore.dll until after it has already instantiated a11y, which is obviously too late for us to hook anything.
Instead, we block UIA instantiation via LazyInstantiator, just as we do for MSAA/IA2:
1. Refactor CompatibilityUIA so that rather than being called by a hook, it simply allows the caller to query the process ids of any UIA clients.
2. CompatibilityUIA now searches handles in our process for named pipes created by UIA for communication with the remote process and then uses GetNamedPipeServerProcessId to get the process id on the other end of each pipe.
3. Refactor LazyInstantiator so that it first tries to get the MSAA/IA2 client process id, then calls CompatibilityUIA to get any UIA client process ids.
4. LazyInstantiator now handles setting the instantiator and blocking of clients for UIA as well as MSAA/IA2 using the same code.
5. Because UIA client detection can be expensive if clients repeatedly query us, cache the result. Reset that cache only when one of our windows comes to the foreground.
Differential Revision: https://phabricator.services.mozilla.com/D181958
Cleans up the interface to AudioSession and brings in line with COM best practices. Uses background threads that are implicitly MTA and asserts proper thread behavior. This also removes AudioSession's Co[Un]Initialize static analysis violations.
Differential Revision: https://phabricator.services.mozilla.com/D140741
The presenting issue is that each background task's audio session is
user-visible via various Windows UIs that display "volume controls" or
"volume mixers"; this avoids that.
Differential Revision: https://phabricator.services.mozilla.com/D141101
Pointer to AudioSession object is made std::atomic to resolve crashes (bug 1755700) by atomically modifying/reading the pointer as an effort to make sure any update to the pointer is seen across other threads immediately while not using locks to maintain such concurrency and avoiding dataraces.
This patch is built upon the work done in D136377.
Differential Revision: https://phabricator.services.mozilla.com/D140741
Helena