Bug 60219 – Unable to Paste After Deleting Text from Input due to -webkit-user-select

• Component: HTML Editing
• Status: RESOLVED FIXED

[Joseph Pecoraro]

Created attachment 92331 [details]
[REDUCTION] Test Case

When removing the final text an <input>, a placeholder <br> element is added.
Later when attempting a paste, a test run takes the -webkit-user-select CSS
property from the placeholder <br> element, which may be different from the
<input> and cause issues.

Test case attached.

[Joseph Pecoraro]

Created attachment 92333 [details]
[PATCH] Skip Possible Placeholders When Getting Context Style for Test Rendering

[Joseph Pecoraro]

FYI: All other LayoutTests/editing tests passed.

[Joseph Pecoraro]

<rdar://problem/9068091>

[Ryosuke Niwa]

Comment on attachment 92333 [details]
[PATCH] Skip Possible Placeholders When Getting Context Style for Test Rendering

It seems like what we want to walk trees until we hit some text node, no?  what if there was img, input, etc...? Should we stop the search before them?

[Darin Adler]

Comment on attachment 92333 [details]
[PATCH] Skip Possible Placeholders When Getting Context Style for Test Rendering

View in context: https://bugs.webkit.org/attachment.cgi?id=92333&action=review

> Source/WebCore/ChangeLog:13
> +        When deleting all the text inside the input a placeholder <br>
> +        element was inserted for the selection point. However, when
> +        pasting, the test run computes the -webkit-user-select for the
> +        <br> element, instead of what would be the text inside the
> +        <input> and incorrectly disallows selection and prevented
> +        the paste.

The real problem here seems to me either that the style rule should not apply to the <br> inside the input element, or we should not use a <br> inside the input element. We don’t want a style rule to have any effect on the elements inside the shadow tree.

Adding a special case to the replace command doesn’t necessarily seem like the right fix to me. It might be OK as a workaround, but it seems a little random.

[Darin Adler]

Comment on attachment 92333 [details]
[PATCH] Skip Possible Placeholders When Getting Context Style for Test Rendering

View in context: https://bugs.webkit.org/attachment.cgi?id=92333&action=review

>> Source/WebCore/ChangeLog:13
>> +        the paste.
> 
> The real problem here seems to me either that the style rule should not apply to the <br> inside the input element, or we should not use a <br> inside the input element. We don’t want a style rule to have any effect on the elements inside the shadow tree.
> 
> Adding a special case to the replace command doesn’t necessarily seem like the right fix to me. It might be OK as a workaround, but it seems a little random.

But on second thought, I do think this is fine as a workaround. Longer term we could find another way to fix this. The <br> does have a special status because of its use as a placeholder.

[Joseph Pecoraro]

(In reply to comment #4)
> (From update of attachment 92333 [details])
> It seems like what we want to walk trees until we hit some
> text node, no?  what if there was img, input, etc...? Should
> we stop the search before them?

I like this idea. Changing the while condition to walk up to
the first TextNode didn't fix this case and caused at least
one other test to fail:

    editing/pasteboard/paste-plaintext-user-select-none.html

I think, with Darin's r+, I'll land this now. I also like the idea
of maybe using something different as a placeholder in this
situation, but I won't attempt that here.

[Joseph Pecoraro]

Landed in r85818: <http://trac.webkit.org/changeset/85818>

[Justin Garcia]

Re-architecting editing to not use brs as placeholders sounds like a big change, and I don't see the reason for it. The bug here is what Darin pointed out, that style rules from the document should not apply to shadow content.

[Ryosuke Niwa]

We need scoped CSS!