dtapuska Reporter
	Description • 6 years ago

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.81 Safari/537.36

Steps to reproduce:

enterkeylabel is a standardization of mozactionhint (with previous addition)

https://github.com/whatwg/html/pull/3538


Actual results:

Not supported


Expected results:

Support the new attribute and pass the WPT tests

	dtapuska Reporter
	Comment 1 • 6 years ago

err.

	dtapuska Reporter
	Comment 2 • 6 years ago

Clearly I wasn't awake when I submitted this. It should reference enterkeyhint

	dtapuska Reporter
	Comment 3 • 6 years ago

Example: http://output.jsbin.com/mukira

	Boris Zbarsky [:bzbarsky]
	Comment 4 • 6 years ago

So if I understand correctly, this requires two changes:

1)  Adding an IDL attribute with reflection for the new attributes.

2)  Adding UI functionality to actually change what the user is shown based on those attributes.

Is that correct?

Should UAs avoid doing #1 until #2 is done, to allow feature-detection?   What should happen on platforms where #2 is not really possible (because there is no virtual keyboard)?

	dtapuska Reporter
	Comment 5 • 6 years ago

You need to do 1).

And for 2 you should already have the support on Android (except for the previous value but should be trivial to add).

This is only used as a hint so feature detection I don't think is necessary. Chrome only has control of this on Android but we do read and reflect the attribute on all platforms.

	Gyula Palko[:gpalko]
	Comment 6 • 6 years ago

Setting the component in order to involve the development team in reviewing this issue.

	Boris Zbarsky [:bzbarsky]
	Comment 7 • 6 years ago

That's the wrong component, as well as the wrong product, for what needs to be done here.

	Boris Zbarsky [:bzbarsky]
	Comment 8 • 6 years ago

So what needs to happen is:

1)  Sending an intent to implement (and ship?)
2)  Adding https://html.spec.whatwg.org/#attr-enterkeyhint ... on which elements?  Spec has it for all HTML elements, but we don't generally support this stuff for non-form-controls.   I still have open questions around feature-detection here and whether sites will end up switching on whether the attribute is present on various types of elements.   In particular, it's not clear to me that we want to support the reflection on elements on which we don't use the attribute.
3)  In IMEStateManager::SetIMEState (in dom/events/IMEStateManager.cpp) we want to consider this attribute in the case where it currently does GetAttr(nsGkAtoms::moz_action_hint).  Looks like that's only for input and textarea, so we may want to limit exposure of the IDL reflection to those elements until that changes...

	Pulsebot
	Comment 22 • 4 years ago

Pushed by m_kato@ga2.so-net.ne.jp:
https://hg.mozilla.org/integration/autoland/rev/7c732d35b397
Part 1. Support HTML.enterKeyHint in Nighly. r=webidl,smaug,hsivonen
https://hg.mozilla.org/integration/autoland/rev/9b7202e779eb
Part 2. Add enterkeyhint attribute to htmlparser. r=hsivonen
https://hg.mozilla.org/integration/autoland/rev/3605a382f0bf
Part 3. InputContext should reference enterkeyhint attribute for action hint. r=masayuki
https://hg.mozilla.org/integration/autoland/rev/bd285002fe0c
Part 4. Split next action hint with next and maybenext. r=masayuki
https://hg.mozilla.org/integration/autoland/rev/e3090704a024
Part 5. Implement current spec of enterkeyhint on Android backend. r=geckoview-reviewers,agi
https://hg.mozilla.org/integration/autoland/rev/2e38bb7fa471
Part 6. Add geckoview-junit test for enterkeyhint. r=geckoview-reviewers,agi