Closed Bug 1079236 Opened 5 years ago Closed 5 years ago

[shadow-dom] Keyboard doesn't appear when <input> is focused

Categories

(Core :: DOM: Core & HTML, defect)

x86
macOS
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla38

People

(Reporter: wilsonpage, Assigned: smaug)

Details

Attachments

(1 file, 1 obsolete file)

When an <input type="text"> within shadow-dom is focused, no device keyboard appears.

TEST-CASE

http://jsbin.com/ponose/1
I don't know what code triggers gaia keyboard to show up.
This could very well be a gaia bug.
Hmm, is this about event.target.
https://mxr.mozilla.org/mozilla-central/source/dom/inputmethod/forms.js?rev=d4b4cca22c19&mark=369-369#340

Assuming it is that, 
a Gecko specific hack would be to use Event.originalTarget
http://mxr.mozilla.org/mozilla-central/source/dom/webidl/Event.webidl#57

Event.path (which is very much underdefined in the spec) would help too.
smaug: Any progress on this, who do we need to ping? Gaia app devs are wanting to use the gaia-text-input [1] web-component in their now, this bug is blocking that.

Doug, could this be a Gaia bug?

[1] https://github.com/gaia-components/gaia-text-input
Flags: needinfo?(drs.bugzilla)
Flags: needinfo?(bugs)
Did some poking around in Gaia and found the 'inputmethod-contextchange' 'mozChrome' event isn't being fired when shadow-dom <input> is focused. System App listens for this mozChromeEvent to know when to show the keyboard [1].

I don't know anything about 'mozChromeEvents', but I believe they come from Gecko. In which case we need to make sure all inputs in shadow-root are correctly emitting these events.

[1] https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/keyboard_manager.js#L216
(I don't see any Gecko code dispatching mozChrome. Looks like b2g stuff uses it.)
Flags: needinfo?(bugs)
Flags: needinfo?(bugs)
So as far as I see, https://mxr.mozilla.org/mozilla-central/source/dom/inputmethod/forms.js?rev=d4b4cca22c19&mark=369-369#340 doesn't deal with shadow dom.
Flags: needinfo?(21)
It is not clear to me how forms.js should even handle focus changes once shadow DOM is implemented
properly since focus event shouldn't even propagate out from the shadow DOM.

I guess we'll need to still pass the event to chrome event targets in the event target chain.
Flags: needinfo?(bugs)
Based on comment 6 and comment 7, it looks like we know the cause.
Flags: needinfo?(drs.bugzilla)
(In reply to Olli Pettay [:smaug] from comment #6)
> So as far as I see,
> https://mxr.mozilla.org/mozilla-central/source/dom/inputmethod/forms.
> js?rev=d4b4cca22c19&mark=369-369#340 doesn't deal with shadow dom.

That's exactly what it is, event retargeting is changing the event target to be the shadow host. The keyboard shows up after changing it to originalTarget.
(In reply to William Chen [:wchen] from comment #9)
> (In reply to Olli Pettay [:smaug] from comment #6)
> > So as far as I see,
> > https://mxr.mozilla.org/mozilla-central/source/dom/inputmethod/forms.
> > js?rev=d4b4cca22c19&mark=369-369#340 doesn't deal with shadow dom.
> 
> That's exactly what it is, event retargeting is changing the event target to
> be the shadow host. The keyboard shows up after changing it to
> originalTarget.

William: How can we get this fixed? Who is able to write a patch?
Flags: needinfo?(wchen)
Need to be just a bit careful to not start using native anonymous content in forms.js, but just
stuff which is in shadow dom. We may need something new in Event, like some [ChromeOnly] attribute
which returns the first non-native-anonymous-content target.
A patch coming... hopefully someone could test it.
Attached patch possible patch (obsolete) — Splinter Review
Anyone want to test this?

I need to still write tests, after lunch.
Attached patch +testSplinter Review
https://tbpl.mozilla.org/?tree=Try&rev=18e04241b5e2
Assignee: nobody → bugs
Attachment #8553084 - Attachment is obsolete: true
Attachment #8553228 - Flags: review?(wchen)
Comment on attachment 8553228 [details] [diff] [review]
+test

Review of attachment 8553228 [details] [diff] [review]:
-----------------------------------------------------------------

I've also verified that this fixes the keyboard issue on the phone.
Attachment #8553228 - Flags: review?(wchen) → review+
Great, thanks a lot!
https://hg.mozilla.org/integration/mozilla-inbound/rev/02786b1385ec
Flags: needinfo?(wchen)
Flags: needinfo?(21)
Thanks for the quick turn around on this Olli, it's a big help! Now we can begin rolling out our form web-components :)
https://hg.mozilla.org/mozilla-central/rev/02786b1385ec
Status: NEW → RESOLVED
Closed: 5 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.