crash nsCaretAccessible::SetControlSelectionListener

RESOLVED FIXED in mozilla22

Status

()

Core
Disability Access APIs
--
critical
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: MarcoZ, Unassigned)

Tracking

({crash})

12 Branch
mozilla22
x86
Windows NT
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

This bug was filed from the Socorro interface and is 
report bp-9e090e1f-dd94-411f-a45f-76f002120310 .
============================================================= 

Reported to me by a community member using JAWS.
Component: Disability Access → Disability Access APIs
Product: Firefox → Core
QA Contact: disability.access → accessibility-apis
Keywords: regressionwindow-wanted

Comment 1

6 years ago
It's a low volume crash with some crashes on 10.0.2:
https://crash-stats.mozilla.com/report/list?signature=nsCaretAccessible%3A%3ASetControlSelectionListener%28nsIContent*%29
Keywords: regressionwindow-wanted

Comment 2

6 years ago
Jim, it sounds like the problem is when window is closed, JAWS is notified about that and does something that sends WM_ACTIVE event so that makes Gecko to fire DOM focus event which is handled by accessibility again. Can you think of the way to prevent things like this, i.e. do not respond to WM_ACTIVATE and maybe some other events when window is destroyed.

Comment 3

6 years ago
It sounds I forgot to cc Jim
Looking at Socorro it seems this happens very rarely. In different stacks I noticed Jaws 11 and Jaws 12 in use.

Seems like we fail with a null mRootAccessible

nsCaretAccessible::SetControlSelectionListener(nsIContent *aCurrentNode)
{
  NS_ENSURE_TRUE(mRootAccessible, NS_ERROR_FAILURE);

Possibly related to our general tree updating pain.

Updated

5 years ago
Flags: needinfo?(jmathies)

Comment 5

5 years ago
(In reply to alexander :surkov from comment #2)
> Jim, it sounds like the problem is when window is closed, JAWS is notified
> about that and does something that sends WM_ACTIVE event so that makes Gecko
> to fire DOM focus event which is handled by accessibility again. Can you
> think of the way to prevent things like this, i.e. do not respond to
> WM_ACTIVATE and maybe some other events when window is destroyed.

Is the widget object still around? If so we have flags in widget - mInDtor and mDestroyCalled that could be used to prevent sending certain events.
Flags: needinfo?(jmathies)

Comment 6

5 years ago
this one was fixed by bug 678477 (rootAccessible doesn't take longer any participation in caret management)
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla14

Updated

5 years ago
Target Milestone: mozilla14 → mozilla22

Updated

5 years ago
Depends on: 678477
You need to log in before you can comment on or make changes to this bug.