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
widget/windows/nsAppShell.cpp(685,10): error: variable 'uiMessage' set but not used [-Werror,-Wunused-but-set-variable]
bool uiMessage = false;
^
widget/windows/TaskbarPreview.cpp(370,11): error: variable 'hr' set but not used [-Werror,-Wunused-but-set-variable]
HRESULT hr;
^
Differential Revision: https://phabricator.services.mozilla.com/D126461
There are no code changes, only #include changes.
It was a fairly mechanical process: Search for all "AUTO_PROFILER_LABEL", and in each file, if only labels are used, convert "GeckoProfiler.h" into "ProfilerLabels.h" (or just add that last one where needed).
In some files, there were also some marker calls but no other profiler-related calls, in these cases "GeckoProfiler.h" was replaced with both "ProfilerLabels.h" and "ProfilerMarkers.h", which still helps in reducing the use of the all-encompassing "GeckoProfiler.h".
Differential Revision: https://phabricator.services.mozilla.com/D104588
Whole firefox only needs one wakelock instance, requesting more wakelock doesn't help anything. As those notification would be sent to chrome process as well, so we would only need one listener in chrome process to prevent requesting unnecessary wakelock.
Differential Revision: https://phabricator.services.mozilla.com/D85818
There's no use case for stateful comparators, so they can be just plain
function pointers.
This is used in some hot places like CSS selector matching.
Differential Revision: https://phabricator.services.mozilla.com/D77084
When we call nsWindow::Show but Firefox is not foreground, we show the window
and also flash it on the taskbar to get the user's attention.
This is really annoying when restoring a session with `N` windows, as the
user's taskbar ends up with all `N` of them stuck in a flashed state until the
user goes through and manually activates every single window.
There are several ways I thought of to address this, but I think the
simplest one is just to track whether or not we're in the middle of restoring a
session and skip flashing when we are doing so.
Differential Revision: https://phabricator.services.mozilla.com/D76406
Both `nsAppShell::ProcessNextNativeEvent()` and `MessagePumpForUI::WaitForWork()` have a `PROFILER_AUTO_THREAD_SLEEP` surrounding the `mozilla::widget::WinUtils::WaitForMessage()` call.
However inside `WaitForMessage()` the call to `PeekMessageW()` may trigger a sequence of events (because the system delivers pending messages) that end in the initialization of a new thread, which invokes `ReentrantMonitor::Wait()` where there is a `PROFILER_AUTO_THREAD_SLEEP`.
To avoid this recursion, this patch moves `PROFILER_AUTO_THREAD_SLEEP` from both callers into `WaitForMessage()` to only enclose the actual potentially-sleeping operation `::MsgWaitForMultipleObjectsEx()`.
Differential Revision: https://phabricator.services.mozilla.com/D72850
Current implementation would fail to request a non-display wakelock on Windows when we ask for a background audio lock. The check for `audio-playing` with `locked-background` is incorrect. Therefore, adding new a variable to tell if we should request a non-display lock.
Differential Revision: https://phabricator.services.mozilla.com/D60201
These are now being hit because of the removal of the HTML frames
customizations to the print dialog.
I've removed the defines for these, because I don't think there is any point
trying to guess what their uses are.
I've also made it 32-bit only, because we only see them on 32-bit Windows 7.
In fact only 32-bit Firefox on 64-bit Windows 7 I believe.
Differential Revision: https://phabricator.services.mozilla.com/D40433
Yannis Juglaret