Ensure that the text trait isSingleLineDocument is set to an appropriate value in Modern WebKit. Legacy WebKit on iOS already does this.
<rdar://problem/60705870>
I take it back. It doesn't look like Legacy WebKit on iOS does this, yet.
Created attachment 394198 [details] Patch and unit test
Created attachment 394199 [details] Patch and unit test
Created attachment 394200 [details] Patch and unit test
Created attachment 394205 [details] Patch and unit test
Created attachment 394206 [details] Patch and unit test
Comment on attachment 394206 [details] Patch and unit test View in context: https://bugs.webkit.org/attachment.cgi?id=394206&action=review r=me if you can get this to build; looks like there are build failures on some bots > Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:4980 > + [_traits setIsSingleLineDocument:(_focusedElementInformation.elementType != WebKit::InputType::TextArea && _focusedElementInformation.elementType != WebKit::InputType::ContentEditable)]; Seems to me this should be backed by a switch statement since we need to look at this list any time we add a new input type and a switch statement without a defauit will helpfully give us an error if a type isn’t listed as one of the cases, which is what we want. Also, is there any practical way to configure a text area or content editable to behave as a single line document? If so, would be nice if doing that gave the correct desired behavior.
Comment on attachment 394206 [details] Patch and unit test View in context: https://bugs.webkit.org/attachment.cgi?id=394206&action=review Thanks for the review. >> Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:4980 >> + [_traits setIsSingleLineDocument:(_focusedElementInformation.elementType != WebKit::InputType::TextArea && _focusedElementInformation.elementType != WebKit::InputType::ContentEditable)]; > > Seems to me this should be backed by a switch statement since we need to look at this list any time we add a new input type and a switch statement without a defauit will helpfully give us an error if a type isn’t listed as one of the cases, which is what we want. > > Also, is there any practical way to configure a text area or content editable to behave as a single line document? If so, would be nice if doing that gave the correct desired behavior. Will use switch block. I wavered up to the last second with a switch block or just this expression. (Went back and forth at least twice). I can use a switch block, what tipped the scale for me was that I realized that <input>s are the only single line document unless you do something excessive... That leads me to answer your question: No, there is not a practical way. There are ways though... Off the top of my head, the optimal way to do so in a <texareas> you have to apply CSS "white-space: nowrap" + prevent the default user agent action for key events that would introduce a newline (e.g. return key, enter key, Control + O on Mac, etc). To be thorough you also need to prevent or remove newlines that are pasted as well as newlines in content dropped into the <textarea>. For contenteditables the optimal way is just with CSS: set "white-space: nowrap" + use a CSS descendant combinator to stylize all children as "display: inline". (Why can't you do the same CSS technique for <textarea>? It is because only a selective set of CSS properties applied to <textarea> are propagated to its user-agent shadom DOM impl.). Anyway, I hope I've convinced you that it's no practical. For now, I'm going with the simple approach in this patch.
Created attachment 394307 [details] To Land
Created attachment 394348 [details] To Land
Comment on attachment 394348 [details] To Land Clearing flags on attachment: 394348 Committed r258919: <https://trac.webkit.org/changeset/258919>
All reviewed patches have been landed. Closing bug.