Tabbing out of a component which has tabindex -1 and shadow root freezes the browser

RESOLVED FIXED in Firefox 67

Status

()

defect
P2
normal
RESOLVED FIXED
3 months ago
2 months ago

People

(Reporter: vilevicius, Assigned: smaug)

Tracking

(Blocks 1 bug, {hang, regression})

65 Branch
mozilla67
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox-esr60 unaffected, firefox65 wontfix, firefox66 wontfix, firefox67 fixed)

Details

Attachments

(2 attachments)

Reporter

Description

3 months ago

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.119 Safari/537.36

Steps to reproduce:

  1. Create simple web component with shadow DOM, slot and tabindex=-1.
  2. Nest component in the same component, add several levels.
  3. Focus node in the top level and press tab.

Here is the code example:
https://codepen.io/anon/pen/ywJqzm

Actual results:

Browser freezes (time of freeze depends on nested levels)

Expected results:

Next focusable element is focused.

Updated

3 months ago
Blocks: shadowdom
Component: Untriaged → DOM
Keywords: hang
Product: Firefox → Core

Comment 1

3 months ago

I can reproduce the gang on Nightly67.0a1 windows10.

Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 2

3 months ago

s/gang/hang/

Comment 3

3 months ago

Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=97898f7472fb0f9e73f4edfb27b2b25e05fd9611&tochange=0dad5cbc6165abc5e395bfb3be995b0da69e7212

Regressed by:
0dad5cbc6165 Olli Pettay — Bug 1466581, handle sequential focus also in nested shadow DOM, r=mrbkap

Blocks: 1466581
Keywords: regression

Updated

3 months ago
Has Regression Range: --- → yes
Has STR: --- → yes

Thanks Alice!

Assignee: nobody → bugs
Priority: -- → P2

Setting to fix-optional for 66 b/c P2

Interesting. It isn't a hang, but (very) slow performance.

Need to write a testcase tomorrow

Component: DOM → DOM: Core & HTML
Product: Core → Core

If aIgnoreTabIndex is true, we're just trying to find any focusable element, doesn't matter which tabindex it has.
So better to bail out early from the deeply nested GetNextTabbableContentInScope to avoid exponential number of calls.

filed bug 1535320 to rename the test file

Comment 11

2 months ago
Pushed by opettay@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/0cc6396199a8
bail out early when trying to find any focusable element in shadow tree, r=masayuki

Comment 12

2 months ago
bugherder
Status: NEW → RESOLVED
Last Resolved: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla67
You need to log in before you can comment on or make changes to this bug.