RESOLVED FIXED209391
[iOS][WK2] Set text trait isSingleLineDocument
https://bugs.webkit.org/show_bug.cgi?id=209391
Summary [iOS][WK2] Set text trait isSingleLineDocument
Daniel Bates
Reported 2020-03-21 23:39:03 PDT
Ensure that the text trait isSingleLineDocument is set to an appropriate value in Modern WebKit. Legacy WebKit on iOS already does this.
Attachments
Patch and unit test (4.32 KB, patch)
2020-03-22 00:00 PDT, Daniel Bates
no flags
Patch and unit test (4.97 KB, patch)
2020-03-22 01:25 PDT, Daniel Bates
no flags
Patch and unit test (5.69 KB, patch)
2020-03-22 01:56 PDT, Daniel Bates
no flags
Patch and unit test (6.02 KB, patch)
2020-03-22 02:11 PDT, Daniel Bates
no flags
Patch and unit test (5.93 KB, patch)
2020-03-22 02:13 PDT, Daniel Bates
no flags
To Land (7.96 KB, patch)
2020-03-23 14:58 PDT, Daniel Bates
no flags
To Land (7.88 KB, patch)
2020-03-23 20:58 PDT, Daniel Bates
no flags
Daniel Bates
Comment 1 2020-03-21 23:39:14 PDT
Daniel Bates
Comment 2 2020-03-21 23:48:32 PDT
I take it back. It doesn't look like Legacy WebKit on iOS does this, yet.
Daniel Bates
Comment 3 2020-03-22 00:00:49 PDT
Created attachment 394198 [details] Patch and unit test
Daniel Bates
Comment 4 2020-03-22 01:25:07 PDT
Created attachment 394199 [details] Patch and unit test
Daniel Bates
Comment 5 2020-03-22 01:56:32 PDT
Created attachment 394200 [details] Patch and unit test
Daniel Bates
Comment 6 2020-03-22 02:11:22 PDT
Created attachment 394205 [details] Patch and unit test
Daniel Bates
Comment 7 2020-03-22 02:13:18 PDT
Created attachment 394206 [details] Patch and unit test
Darin Adler
Comment 8 2020-03-22 09:44:39 PDT
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.
Daniel Bates
Comment 9 2020-03-23 14:56:00 PDT
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.
Daniel Bates
Comment 10 2020-03-23 14:58:12 PDT
Daniel Bates
Comment 11 2020-03-23 20:58:39 PDT
Daniel Bates
Comment 12 2020-03-24 10:57:45 PDT
Comment on attachment 394348 [details] To Land Clearing flags on attachment: 394348 Committed r258919: <https://trac.webkit.org/changeset/258919>
Daniel Bates
Comment 13 2020-03-24 10:57:46 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.