https://html.spec.whatwg.org/multipage/interaction.html#input-modalities%3A-the-inputmode-attribute This will ship in Blink/Chrome 66: https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/inputmode/blink-dev/MAHQkH4vvUQ/i0yCobrMCQAJ
Created attachment 347340 [details] Patch
Created attachment 347396 [details] Patch
Created attachment 347413 [details] Patch
Comment on attachment 347413 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=347413&action=review > Source/WebCore/html/InputModeNames.cpp:77 > +} // namespace WebCore::InputModeNames // namespace InputModeNames > Source/WebCore/html/InputModeNames.h:42 > +} Ditto. > Source/WebKit/Shared/AssistedNodeInformation.h:61 > +enum class InputMode { We should specify a size fo this enum to get better packing. Otherwise, this enum will default to the width of int. > Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:3554 > + default: I suggest we remove this "default" case and list any other enumerators. This will allow the compiler to ensure that this switch handles all enumerators. > Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm:2302 > +static InputMode inputModeForElement(const Node& node) Can we come up with a better name for this?
> duplicate symbol __ZN7WebCore14InputModeNames7numericEv in: > /Volumes/Data/EWS/WebKit/WebKitBuild/WebCore.build/Release-iphonesimulator/WebCore.build/Objects-normal/x86_64/InputModeNames.o > /Volumes/Data/EWS/WebKit/WebKitBuild/WebCore.build/Release-iphonesimulator/WebCore.build/Objects-normal/x86_64/UnifiedSource269.o > ld: 7 duplicate symbols for architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see invocation) Is InputModeNames.cpp being included in the WebCore target, as well appearing in one of the unified source files?
Created attachment 347504 [details] Patch
Created attachment 347720 [details] Patch
Added an API test to verify we show the correct keyboard for a variety of input configurations.
Comment on attachment 347720 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=347720&action=review > Tools/TestWebKitAPI/Tests/ios/KeyboardInputTestsIOS.mm:192 > + NSArray *inputModes = @[ @"", @"text", @"tel", @"url", @"email", @"numeric", @"decimal", @"search" ]; Could create this from the dictionary with -allKeys. Except "" I guess... I dunno. > Tools/TestWebKitAPI/Tests/ios/KeyboardInputTestsIOS.mm:203 > + NSArray *inputTypesWithKeyboard = @[ @"text", @"password", @"search", @"email", @"tel", @"number", @"url" ]; Could create this from the dictionary with -allKeys
Created attachment 347812 [details] Patch
Created attachment 347820 [details] Patch for landing
Comment on attachment 347820 [details] Patch for landing Clearing flags on attachment: 347820 Committed r235201: <https://trac.webkit.org/changeset/235201>
Comment on attachment 347820 [details] Patch for landing View in context: https://bugs.webkit.org/attachment.cgi?id=347820&action=review > Source/WebCore/ChangeLog:8 > + Added the inputmode attribute to the HTMLInputElement and HTMLTextAreaElement IDL It is an unwritten convention that we reference the spec. and version/date of the spec. in the ChangeLog when adding new web exposed functionality. One example of such a ChangeLog (though it does not include a date) is <https://trac.webkit.org/changeset/234680/>. This records the spec you referenced when writing this patch. > Source/WebCore/html/HTMLTextAreaElement.idl:62 > + attribute DOMString inputMode; As per <https://html.spec.whatwg.org/multipage/interaction.html#dom-inputmode> this should be a reflected attribute. Please add "[Reflect]" before "attribute". > Source/WebCore/html/HTMLTextFormControlElement.cpp:678 > +String HTMLTextFormControlElement::inputMode() const How did you come to the decision to return a String instead of returning an const AtomicString&? I mean, returning a String causes unnecessary ref-count churn. > Source/WebCore/html/HTMLTextFormControlElement.cpp:702 > +void HTMLTextFormControlElement::setInputMode(const String& value) > +{ > + setAttributeWithoutSynchronization(inputmodeAttr, value); > +} This function is unnecessary when the attribute is marked "[Reflect]" in the IDL.
<rdar://problem/43623657>
(In reply to Daniel Bates from comment #13) > > Source/WebCore/html/HTMLTextAreaElement.idl:62 > > + attribute DOMString inputMode; > > As per > <https://html.spec.whatwg.org/multipage/interaction.html#dom-inputmode> this > should be a reflected attribute. Please add "[Reflect]" before "attribute". > Disregard this remark. Our binding generator code does not support reflections with a custom getter. > [...] > > > Source/WebCore/html/HTMLTextFormControlElement.cpp:702 > > +void HTMLTextFormControlElement::setInputMode(const String& value) > > +{ > > + setAttributeWithoutSynchronization(inputmodeAttr, value); > > +} > > This function is unnecessary when the attribute is marked "[Reflect]" in the > IDL. Disregard this remark.
So looking at the patch set it looks like you might have only implemented half of it. There doesn't seem to be any "none" support and this is missing the attribute on the HTML element which is useful for content editable. Is this really resolved fixed? Or are more patches coming? If not can you share justification for diverging from the specification?
(In reply to David Tapuska from comment #16) > So looking at the patch set it looks like you might have only implemented > half of it. There doesn't seem to be any "none" support and this is missing > the attribute on the HTML element which is useful for content editable. > > Is this really resolved fixed? Or are more patches coming? If not can you > share justification for diverging from the specification? I have a patch forthcoming for the contenteditable case.
None support is used by some of Google's productivity apps that have a content editable item but don't wish a keyboard to be present. For example presentation mode in Google Slides.
*** Bug 161506 has been marked as a duplicate of this bug. ***
Hello This has been shipped in Chrome and I see it has been marked as fixed here for months. I am writing this hoping it gets noticed by someone who can verify it so it can make its way into Safari soon enough. Many thanks everyone.
Emanuele, This will ship in iOS 12.2, which is currently in beta.
Best news of the week. Thanks!