Open Bug 1490661 Opened 2 years ago Updated 3 days ago

Support enterkeyhint and deprecate mozactionhint

Categories

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

defect

Tracking

()

People

(Reporter: dtapuska, Assigned: m_kato)

References

Details

(Keywords: dev-doc-needed, site-compat)

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
Summary: Support enterkeylabel and deprecate mozactionhint → Support enterkeyhint nd deprecate mozactionhint
err.
Summary: Support enterkeyhint nd deprecate mozactionhint → Support enterkeyhint and deprecate mozactionhinta
Clearly I wasn't awake when I submitted this. It should reference enterkeyhint
Example: http://output.jsbin.com/mukira
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)?
Flags: needinfo?(dtapuska)
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.
Flags: needinfo?(dtapuska)
Keywords: site-compat
Setting the component in order to involve the development team in reviewing this issue.
Component: Untriaged → Keyboard Navigation
That's the wrong component, as well as the wrong product, for what needs to be done here.
Status: UNCONFIRMED → NEW
Component: Keyboard Navigation → DOM
Ever confirmed: true
Product: Firefox → Core
Summary: Support enterkeyhint and deprecate mozactionhinta → Support enterkeyhint and deprecate mozactionhint
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...
Priority: -- → P2
Component: DOM → DOM: Core & HTML

Also, this has unclear issue for event model. https://github.com/w3c/uievents/issues/253

I see people promoting this now that Safari has shipped: https://twitter.com/stefanjudis/status/1249958064041734144

Yoshino-san, although you set site-compat keyword, do you know whether any major site already uses this attribute?

To ship this on us, we have to clear ui event issue per comment #9. Although I ask it to dtapuska, no response.

Sorry I missed that. We always fire enter events if the attribute is specified. The specification could likely be cleaned up.

(In reply to dtapuska from comment #12)

Sorry I missed that. We always fire enter events if the attribute is specified. The specification could likely be cleaned up.

Thank you. I already have a prototype for this implementation, so I am considering this for GeckoView.

(In reply to Makoto Kato [:m_kato] from comment #11)

Yoshino-san, although you set site-compat keyword, do you know whether any major site already uses this attribute?

I don’t know any specific case but will post a site compatibility note anyway for the deprecation.

Assignee: nobody → m_kato
You need to log in before you can comment on or make changes to this bug.