Closed Bug 1771271 Opened 2 years ago Closed 2 years ago

102.0a1 Crash Report PLDHashTable::Search | mozilla::a11y::RemoteAccessibleBase<T>::RetrieveCachedBounds

Categories

(Core :: Disability Access APIs, defect)

Firefox 102
ARM64
Android
defect

Tracking

()

RESOLVED FIXED
103 Branch
Tracking Status
firefox-esr91 --- unaffected
firefox101 --- unaffected
firefox102 --- fixed
firefox103 --- fixed

People

(Reporter: qjfkcovb3, Assigned: eeejay)

References

Details

(Keywords: crash, Whiteboard: [ctw-m1])

Crash Data

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Firefox/102.0

Expected results:

Please refer to this Socorro:

https://crash-stats.mozilla.org/report/index/f41d3b5a-53f6-4f21-9620-d6e390220526#tab-details

Summary: PLDHashTable::Search | mozilla::a11y::RemoteAccessibleBase<T>::RetrieveCachedBounds → 102.0a1 Crash Report PLDHashTable::Search | mozilla::a11y::RemoteAccessibleBase<T>::RetrieveCachedBounds

The Bugbug bot thinks this bug should belong to the 'Firefox::Search' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Search
Component: Search → Untriaged
Component: Untriaged → Disability Access APIs
Product: Firefox → Core

RetrieveCachedBounds should null check mCachedFields. That said, mCachedFields really shouldn't be null - it should contain bounds at the very least - unless we somehow tried to populate an Android node after it was shown but before the cache was sent. I wonder if that's a race condition we actually need to worry about? Eitan, thoughts?

Blocks: a11y-ctw
Flags: needinfo?(eitan)
Keywords: crash
OS: Unspecified → Android
Hardware: Unspecified → ARM64
Whiteboard: [ctw-m1]

Since the cache push does not happen in line with remote tree creation, and since we dispatch the show event before the cache is populated, this is very possible.

We do check for mCachedFields in BoundsWithOffset, butonly for this, not for its ancestors. Need to fix that.

Flags: needinfo?(eitan)

It is a bit confounding that an ancestor would not have a cache bundle. perhaps it is the result of a move of some kind, or an embedded doc?

Assignee: nobody → eitan
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Pushed by eisaacson@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/cc8cef05c105
Check for mCachedFields for all remote accessibles in BoundsWithOffset. r=morgan
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 103 Branch

Copying crash signatures from duplicate bugs.

Crash Signature: [@ PLDHashTable::Search | mozilla::a11y::RemoteAccessibleBase<T>::RetrieveCachedBounds]

Eitan, this fix seems to be effective, could you request an uplift to beta? Thanks!

Flags: needinfo?(eitan)

Comment on attachment 9278987 [details]
Bug 1771271 - Check for mCachedFields for all remote accessibles in BoundsWithOffset. r?morgan

Beta/Release Uplift Approval Request

  • User impact if declined: Fixes crash
  • 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:
  • Is Android affected?: Yes
Flags: needinfo?(eitan)
Attachment #9278987 - Flags: approval-mozilla-beta?

Comment on attachment 9278987 [details]
Bug 1771271 - Check for mCachedFields for all remote accessibles in BoundsWithOffset. r?morgan

Approved for 102 beta 6, thanks.

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

Attachment

General

Created:
Updated:
Size: