Closed
Bug 1476301
Opened 6 years ago
Closed 5 years ago
[FIX] Focus trap into webcomponents with shadowDOM
Categories
(Core :: DOM: Core & HTML, defect, P3)
Tracking
()
RESOLVED
FIXED
mozilla63
Tracking | Status | |
---|---|---|
firefox63 | --- | fixed |
People
(Reporter: xaviermd, Assigned: smaug)
References
Details
(Keywords: nightly-community)
Attachments
(3 files, 1 obsolete file)
1.03 KB,
text/html
|
Details | |
4.98 KB,
patch
|
mrbkap
:
review+
|
Details | Diff | Splinter Review |
4.93 KB,
patch
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:63.0) Gecko/20100101 Firefox/63.0 Build ID: 20180716100102 Steps to reproduce: - Go on https://dascritch.net/vrac/.projets/audiowc/index.html (NOTE : <import> polyfilled) or download https://github.com/dascritch/cpu-audio/releases/tag/5.pre1 - Use →tab to move focus in the page Actual results: Once the focus is into a shadowDOM of the webcomponent, the focus cannot go outside forward or backward Expected results: The focus must continue to go forward
Updated•6 years ago
|
Keywords: nightly-community
Reporter | ||
Comment 1•6 years ago
|
||
I find out a part of the answer : The shadowRoot of my WebComponent has “2 tabindex="0"” declarations in the <template> tag : <div class="interface" tabindex="0"> <div class="principal"> <img class="poster nosmall" src="" alt="" /> <div class="pageerror"> </div> <div class="pagemain"> <a class="control" tabindex="0"> If I put different positive numbers, I have less problems, excepted that the focus became really erratic. Afterwards ( https://github.com/dascritch/cpu-audio/tree/39e9e18697afbf18d3ef6b782b74cd130ad8fbb6 ), I added some code to support a <menu>, with tabindex="0" added via innerHTML : line.innerHTML = `<a href="#${self.audiotag.id}&t=${cuepoint}" tabindex="0"> <strong>${cue.text}</strong> <span>${cuetime}</span> </a>`; Funnily, the webcomponent is not reacting the same way, as you can focus backwards via [shift]+[tab], but you're still trapped in. I can try to add programmatically element.tabindex, but it means a lot of undesired complexity. Chrome works as desired. May be it is a bug due to their webcomponents.js polyfill ? It means my code really needs a native <link rel="import"> support.
Updated•5 years ago
|
Priority: -- → P3
Assignee | ||
Comment 2•5 years ago
|
||
Any chance for a minimal testcase attached to this bug?
Flags: needinfo?(xaviermd)
Assignee | ||
Updated•5 years ago
|
Blocks: shadowdom-initial-release
Reporter | ||
Comment 4•5 years ago
|
||
Here is the minimal testcase. When you move your focus with the [tab] key (or [shift]+[tab] for backwards), once the focus enters into a webcomponent, it cannot evade it.
Reporter | ||
Comment 5•5 years ago
|
||
Adding style for a better visibility
Attachment #8998222 -
Attachment is obsolete: true
Assignee | ||
Comment 6•5 years ago
|
||
Great, thanks. I'll try to look at this tomorrow
Assignee | ||
Comment 7•5 years ago
|
||
ok, hmm, I think I've fixed that issue already once before. And I thought I had added a testcase :/
Assignee | ||
Updated•5 years ago
|
Assignee: nobody → bugs
Assignee | ||
Updated•5 years ago
|
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Assignee | ||
Comment 8•5 years ago
|
||
On could argue this is a bug in FrameTraversal, since it deals with inline elements differently. The key point in the test is that host is not div, but span. (there is another sequential bug in shadow DOM, so I may need to tweak this code still a bit.)
Attachment #8998675 -
Flags: review?(mrbkap)
Assignee | ||
Updated•5 years ago
|
Summary: [WebComponents] Focus trap into webcomponents with shadowDOM → [FIX] Focus trap into webcomponents with shadowDOM
Comment 9•5 years ago
|
||
Comment on attachment 8998675 [details] [diff] [review] shadowdomw_inline_host_focus.diff Review of attachment 8998675 [details] [diff] [review]: ----------------------------------------------------------------- ::: dom/base/nsFocusManager.cpp @@ +3599,5 @@ > nsIContent* currentContent = frame->GetContent(); > nsIContent* oldTopLevelHost = currentTopLevelHost; > + if (oldTopLevelHost != currentContent) { > + nsIContent* topLevel = GetTopLevelHost(currentContent); > + currentTopLevelHost = topLevel; Nit: no need for the temporary `topLevel`.
Attachment #8998675 -
Flags: review?(mrbkap) → review+
Assignee | ||
Comment 10•5 years ago
|
||
Comment 11•5 years ago
|
||
Pushed by opettay@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/96daed2c2310 try to ensure sequential focusing can leave shadow trees, r=mrbkap
Comment 12•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/96daed2c2310
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
status-firefox63:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
Reporter | ||
Comment 13•5 years ago
|
||
I just checked and.... keyboard focus is still trapped in a little more complex page. What i have missed ? https://dascritch.net/vrac/.projets/audiowc/index.html
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 14•5 years ago
|
||
Could you open a new bug, please. The patch in this bug fixed the issue shown by the testcase.
Status: REOPENED → RESOLVED
Closed: 5 years ago → 5 years ago
Flags: needinfo?(xaviermd)
Resolution: --- → FIXED
Reporter | ||
Comment 15•5 years ago
|
||
Yes, i will. But i still don't understand where the problem lies, and so how to reproduce it.
Flags: needinfo?(xaviermd)
Reporter | ||
Updated•5 years ago
|
Flags: needinfo?(xaviermd)
Comment 16•5 years ago
|
||
I also encountered a complicated situations where shadow dom focusable elements cannot be tabbed to, and right now I also haven't found the virutal cause where the issue lies. Uploading the whole document and styles seems an overkill
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•