Bug 60219 - Unable to Paste After Deleting Text from Input due to -webkit-user-select
Summary: Unable to Paste After Deleting Text from Input due to -webkit-user-select
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2011-05-04 15:35 PDT by Joseph Pecoraro
Modified: 2011-05-13 16:07 PDT (History)
8 users (show)

See Also:


Attachments
[REDUCTION] Test Case (221 bytes, text/html)
2011-05-04 15:35 PDT, Joseph Pecoraro
no flags Details
[PATCH] Skip Possible Placeholders When Getting Context Style for Test Rendering (4.47 KB, patch)
2011-05-04 15:47 PDT, Joseph Pecoraro
darin: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Joseph Pecoraro 2011-05-04 15:35:51 PDT
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.
Comment 1 Joseph Pecoraro 2011-05-04 15:47:29 PDT
Created attachment 92333 [details]
[PATCH] Skip Possible Placeholders When Getting Context Style for Test Rendering
Comment 2 Joseph Pecoraro 2011-05-04 15:48:17 PDT
FYI: All other LayoutTests/editing tests passed.
Comment 3 Joseph Pecoraro 2011-05-04 15:48:57 PDT
<rdar://problem/9068091>
Comment 4 Ryosuke Niwa 2011-05-04 16:04:20 PDT
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?
Comment 5 Darin Adler 2011-05-04 16:06:21 PDT
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.
Comment 6 Darin Adler 2011-05-04 16:07:35 PDT
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.
Comment 7 Joseph Pecoraro 2011-05-04 17:35:01 PDT
(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.
Comment 8 Joseph Pecoraro 2011-05-04 18:18:00 PDT
Landed in r85818: <http://trac.webkit.org/changeset/85818>
Comment 9 Justin Garcia 2011-05-13 16:03:31 PDT
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.
Comment 10 Ryosuke Niwa 2011-05-13 16:07:38 PDT
We need scoped CSS!