Closed Bug 1677934 Opened 4 years ago Closed 4 years ago

Crash in [@ -[MOXTextMarkerDelegate moxUIElementForTextMarker:]]


(Core :: Disability Access APIs, defect, P1)

Firefox 85



86 Branch
Tracking Status
firefox-esr78 --- unaffected
firefox84 --- wontfix
firefox85 --- fixed
firefox86 --- fixed


(Reporter: MarcoZ, Assigned: eeejay)


(Keywords: crash, Whiteboard: [Mac2020_2])

Crash Data


(1 file)

Crash report:


Top 10 frames of crashing thread:

0 XUL -[MOXTextMarkerDelegate moxUIElementForTextMarker:] accessible/mac/
1 XUL -[MOXAccessibleBase accessibilityAttributeValue:forParameter:] accessible/mac/
2 AppKit ___NSAccessibilityEntryPointValueForAttributeWithParameter_block_invoke.840 
3 AppKit NSAccessibilityPerformEntryPointObject 
4 AppKit NSAccessibilityEntryPointValueForAttributeWithParameter 
5 AppKit CopyParameterizedAttributeValue 
6 HIServices _AXXMIGCopyParameterizedAttributeValue 
7 HIServices _XCopyParameterizedAttributeValue 
8 HIServices mshMIGPerform 

I was reproducing a user reported perf issue on Mac and was interacting with the resulting page. I had VoiceOver on and a Braille display connected.

  1. Opened this text file in TextEdit and copied the whole string to the clipboard.
  2. Went to the screen reader version of Trimps.
  3. Navigated to "Import", pasted the contents into the text field, and hit "Import" button.
  4. Navigated the result. Interacted, navigated, stopped interacting. I believe the crash happened when I once went out of, and then back into, the web content itself.

When I try to reproduce. The website just churns info for a long time after pressing import. Do you need to wait for all that to finish first?

Flags: needinfo?(mzehe)

Oh interesting, I was under the impression the import had finished. There was info I was able to browse with VoiceOver just a few seconds after hitting Import. The original report from the user said that Firefox appeared to be munching on the data, whereas Chrome would return the imported data instantly. I thought this was a problem on Windows only, and since I was on the Mac, tried to (not) reproduce the problem there, where I hit this crash. But if Firefox takes a long time to process the data for you as well, it appears that the original report is valid for Firefox in general, and not accessibility-related. The crash may then have been the cause of something updating unexpectedly.

Flags: needinfo?(mzehe)

This doesn't happen often. I can't find a reproducable case to test with. This happens with rapidly mutating content and is the result of some kind of race.

Assignee: nobody → eitan
Pushed by
Check for null when getting leaf for text marker. r=morgan
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 86 Branch

The patch landed in nightly and beta is affected.
:eeejay, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Flags: needinfo?(eitan)

Comment on attachment 9194049 [details]
Bug 1677934 - Check for null when getting leaf for text marker. r?morgan!

Beta/Release Uplift Approval Request

  • User impact if declined: Potential for crashes
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): This is a simple null check
  • String changes made/needed:
Flags: needinfo?(eitan)
Attachment #9194049 - Flags: approval-mozilla-beta?

Comment on attachment 9194049 [details]
Bug 1677934 - Check for null when getting leaf for text marker. r?morgan!

crash fix, approved for 85.0b8

Attachment #9194049 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
You need to log in before you can comment on or make changes to this bug.