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

Status: RESOLVED FIXED

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

Description

[Wilson Page [:wilsonpage]]

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

TEST-CASE

http://jsbin.com/ponose/1

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

I don't know what code triggers gaia keyboard to show up.
This could very well be a gaia bug.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

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.

Comment 3

[Wilson Page [:wilsonpage]]

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

Comment 4

[Wilson Page [:wilsonpage]]

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

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

(I don't see any Gecko code dispatching mozChrome. Looks like b2g stuff uses it.)

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

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.

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

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.

Comment 8

[Doug Sherk (:drs) (inactive)]

Based on comment 6 and comment 7, it looks like we know the cause.

Comment 9

[William Chen [:wchen]]

(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.

Comment 10

[Wilson Page [:wilsonpage]]

(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?

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

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.

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

A patch coming... hopefully someone could test it.

Comment 13

[Olli Pettay [:smaug][[e-mail]]]

Attachment: possible patch

Anyone want to test this?

I need to still write tests, after lunch.

Comment 14

[Olli Pettay [:smaug][[e-mail]]]

Attachment: +test

https://tbpl.mozilla.org/?tree=Try&rev=18e04241b5e2

Comment 15

[William Chen [: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.

Comment 16

[Olli Pettay [:smaug][[e-mail]]]

Great, thanks a lot!

Comment 17

[Olli Pettay [:smaug][[e-mail]]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/02786b1385ec

Comment 18

[Wilson Page [:wilsonpage]]

Thanks for the quick turn around on this Olli, it's a big help! Now we can begin rolling out our form web-components :)

Comment 19

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/02786b1385ec