Frequently hitting Assertion failure: count == (aShouldHide ? -1 : 0), at widget/windows/nsWindow.cpp:688
Categories
(Core :: Widget: Win32, defect, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr91 | --- | unaffected |
| firefox100 | --- | unaffected |
| firefox101 | --- | wontfix |
| firefox102 | --- | fixed |
People
(Reporter: Jamie, Assigned: handyman)
References
(Regression)
Details
(Keywords: regression)
Attachments
(1 file)
I'm hitting this assertion failure whenever I exit a Firefox debug build and whenever I try to focus the address bar. (It probably happens elsewhere too; those are just the two cases I've reproduced so far.)
I haven't debugged this, but I think this might be happening because the desktop I'm using is headless and does not have a mouse connected. The documentation for ShowCursor says:
If a mouse is installed, the initial display count is 0. If no mouse is installed, the display count is –1.
Updated•4 years ago
|
Comment 1•4 years ago
|
||
Set release status flags based on info from the regressing bug 1759558
Comment 2•4 years ago
|
||
:handyman, since you are the author of the regressor, bug 1759558, could you take a look?
For more information, please visit auto_nag documentation.
Updated•4 years ago
|
| Assignee | ||
Comment 3•4 years ago
|
||
I guess this is also a concern for touch screens with no mouse.
I've got something working that determines if a mouse exists by calling ShowCursor (twice -- on and off) during startup. Alternatively, we could iterate over the devices, looking for a mouse. After that, I'm gating MaybeHideCursor on the boolean. But I think we'll also need to detect if a mouse is (dis)connected and update that boolean. I'm still investigating but I assume Windows doesn't do anything to an app's thread's cursor state when a mouse is (dis)connected -- otherwise the count would be mismatched. So we'll also need to expose/hide the cursor in that event.
| Assignee | ||
Comment 4•4 years ago
|
||
TL;DR We should treat the no-mouse case the same as the widget.windows.hide_cursor_when_typing pref being off and skip the ShowCursor calls. Tablet mode is unrelated.
--
Some facts seem to suggest that common touch setups don't have an issue here:
- On a Surface laptop with a detachable screen for tablet mode, nightly behaves well in all cases. Notably, the
ShowCursorcount says it is based on whether a mouse is installed and I'm seeing '0' (meaning a mouse is installed) even in tablet mode. So the count behavior is as desired. - What is unusual is that the cursor is never shown in tablet mode, not even if you want it to be (assuming this behavior hasn't been added). This is what we want but also suggests they don't handle the cases in Raymond Chen's blog post on the subject.
So when in tablet mode, we maintain the count as if we weren't in tablet mode, and everything seems fine.
As for Jamie's case in comment 0, all this seems to suggest that we can treat the case where we start with the cursor count as '-1' the same as the widget.windows.hide_cursor_when_typing pref being off -- so, not calling ShowCursor. (FYI, the pref also works as a temporary workaround for this bug.) Or we could maintain the count but offset by -1 (just update the assert), which is the old-school way of handling the cases in the blog post that MS had in mind but seems to have abandoned with this tablet behavior. The second option would make sense if we needed to detect and handle a mouse being attached (and I guess installed) but, since that is not how tablet-mode behaves, I don't think we need to.
Comment 5•4 years ago
|
||
Is there a real-world impact for this bug beyond the assert being hit in debug builds?
| Assignee | ||
Comment 6•4 years ago
|
||
This is a MOZ_ASSERT, not a MOZ_RELEASE_ASSERT so it should be ok. Fix looks to be to base the count on the initial ShowCursor value, assuming comment 4 is correct, which I am still checking.
Updated•4 years ago
|
| Assignee | ||
Comment 7•4 years ago
|
||
We don't need to track cursor hiding when typing if there shouldn't be a cursor anyway because there is no mouse.
Updated•4 years ago
|
Comment 9•4 years ago
|
||
| bugherder | ||
Description
•