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.
Created attachment 92333 [details] [PATCH] Skip Possible Placeholders When Getting Context Style for Test Rendering
FYI: All other LayoutTests/editing tests passed.
<rdar://problem/9068091>
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 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 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.
(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.
Landed in r85818: <http://trac.webkit.org/changeset/85818>
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.
We need scoped CSS!