[iOS][WK2] Set text trait isSingleLineDocument

• Component: WebKit Misc.
• Status: RESOLVED FIXED

[Daniel Bates]

Ensure that the text trait isSingleLineDocument is set to an appropriate value in Modern WebKit. Legacy WebKit on iOS already does this.

[Daniel Bates]

<rdar://problem/60705870>

[Daniel Bates]

I take it back. It doesn't look like Legacy WebKit on iOS does this, yet.

[Daniel Bates]

Created attachment 394198 [details]
Patch and unit test

[Daniel Bates]

Created attachment 394199 [details]
Patch and unit test

[Daniel Bates]

Created attachment 394200 [details]
Patch and unit test

[Daniel Bates]

Created attachment 394205 [details]
Patch and unit test

[Daniel Bates]

Created attachment 394206 [details]
Patch and unit test

[Darin Adler]

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 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]

Created attachment 394307 [details]
To Land

[Daniel Bates]

Created attachment 394348 [details]
To Land

[Daniel Bates]

Comment on attachment 394348 [details]
To Land

Clearing flags on attachment: 394348

Committed r258919: <https://trac.webkit.org/changeset/258919>

[Daniel Bates]

All reviewed patches have been landed.  Closing bug.