Closed Bug 1528034 Opened 7 years ago Closed 7 years ago

Browser tab crashes when tabbing after the previous tab target is removed

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P3)

defect

Tracking

()

RESOLVED FIXED
mozilla67
Tracking Status
firefox-esr60 --- unaffected
firefox65 --- unaffected
firefox66 --- fixed
firefox67 --- fixed

People

(Reporter: mstriemer, Assigned: smaug)

Details

(Keywords: crash, Whiteboard: [qa-66b-p2])

Crash Data

Attachments

(1 file)

I originally noticed this while working on about:addons, where the entire browser would crash when this happened. I copied my code to glitch.com [1] to check if it happens in web content and it will crash [2] the tab there.

STR

  1. Tab to focus the Disable option
  2. Press space/enter to hide the element
  3. Press Tab

Expected results: The next tab target is selected
Actual results: The tab crashes

[1] https://shrouded-saturday.glitch.me/
[2] https://crash-stats.mozilla.com/report/index/3250602e-9564-4373-8a10-a65290190214

Crash Signature: [@ nsFocusManager::GetNextTabbableContent]
Keywords: crash
Priority: -- → P3

Looks like that nullptr access in nsFocusManager.

Flags: needinfo?(enndeakin)

I was looking at the crash report and it wasn't quite clear to me where the null pointer crash actually happens.

The crash seems to happen at https://searchfox.org/mozilla-central/rev/e6520f0a4dd5d7474c32a1164744953ea59be0d0/dom/base/nsFocusManager.cpp#3162 as the result of the call to FindOwner -- which can return null -- is then passed to IsHostOrSlot which expects its argument to be non-null.

I don't know much about any of this code since it was added for some shadow dom stuff.

Flags: needinfo?(enndeakin)

Indeed, thanks.

Assignee: nobody → bugs
Attached patch null checkSplinter Review

we can just make IsHostOrSlot null-safe

Attachment #9044461 - Flags: review?(enndeakin)
Attachment #9044461 - Flags: review?(enndeakin) → review+
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla67

Should we take this on Beta too?

Blocks: 1513141
Flags: needinfo?(bugs)

Bug 1513141 only refactored code, there was no null-check before either.

No longer blocks: 1513141

Comment on attachment 9044461 [details] [diff] [review]
null check

Beta/Release Uplift Approval Request

  • Feature/Bug causing the regression: Bug 1471947
  • User impact if declined: Crashes.
    Possibly a regression from enabling shadow DOM.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: No
  • 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): Null check
  • String changes made/needed: NA
Flags: needinfo?(bugs)
Attachment #9044461 - Flags: approval-mozilla-beta?
Comment on attachment 9044461 [details] [diff] [review] null check Fix for a rare crash. The fix is simple so let's bring it to beta 12.
Attachment #9044461 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Whiteboard: [qa-66b-p2]
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: