Bug 80502

Summary: Editing caret should skip elements with shadow dom.
Product: WebKit Reporter: Hajime Morrita <morrita>
Component: HTML EditingAssignee: Hajime Morrita <morrita>
Status: NEW    
Severity: Normal CC: dglazkov, rniwa, webkit.review.bot
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 82697    
Attachments:
Description Flags
Patch
none
Patch webkit.review.bot: commit-queue-

Hajime Morrita
Reported 2012-03-07 01:02:48 PST
Currently caret isn't aware the shadow and its movement is broken over the shadow-backed elements. It should behave as if it is a replaced element.
Attachments
Patch (8.22 KB, patch)
2012-03-07 02:28 PST, Hajime Morrita 		no flags
DetailsFormatted DiffDiff
Patch (10.96 KB, patch)
2012-03-12 04:13 PDT, Hajime Morrita 		webkit.review.bot: commit-queue-
DetailsFormatted DiffDiff
Show Obsolete (2) View All Add attachment proposed patch, testcase, etc.
Hajime Morrita
Comment 1 2012-03-07 02:28:07 PST
Created attachment 130576 [details] Patch
Hajime Morrita
Comment 2 2012-03-07 02:30:06 PST
Hi Dimitri, could you take a look? Maybe we could be better by take <content> in account somehow butI have no clear idea yet. And current behavior is simple broken. I thinks It's worth fixing.
WebKit Review Bot
Comment 3 2012-03-07 04:31:19 PST
Comment on attachment 130576 [details] Patch Attachment 130576 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/11835964 New failing tests: svg/text/text-path-01-b.svg svg/custom/use-clipped-hit.svg
Ryosuke Niwa
Comment 4 2012-03-07 08:31:07 PST
Comment on attachment 130576 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=130576&action=review > Source/WebCore/html/HTMLDetailsElement.cpp:163 > + // The UA Shadow guarantees all content is distributed, but it's not true for author shadows. > + return 1 == shadowTree()->size(); I don't understand. Why it's okay for selection to be inside the light dom when there are more than 1 shadow trees? > LayoutTests/editing/selection/move-over-shadow.html:6 > +<div id="container" contentEditable>A<span id="host1"></span><span id="host2"></span>C</div> This test is kind of bogus. Because spans are empty, WebKit will never put selection endpoints inside them even without this change. > LayoutTests/editing/selection/move-over-shadow.html:8 > +<script><!-- <!--? > LayoutTests/editing/selection/move-over-shadow.html:18 > +var sel = window.getSelection(); Please do't use abbreviations like sel.
Ryosuke Niwa
Comment 5 2012-03-07 08:35:03 PST
Comment on attachment 130576 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=130576&action=review >> LayoutTests/editing/selection/move-over-shadow.html:6 >> +<div id="container" contentEditable>A<span id="host1"></span><span id="host2"></span>C</div> > > This test is kind of bogus. Because spans are empty, WebKit will never put selection endpoints inside them even without this change. I guess without this patch, selection code would have moved from ("A", 0) to ("C", 0) in one step. But we should still test the case when spans have contents.
Dimitri Glazkov (Google)
Comment 6 2012-03-07 08:54:29 PST
Comment on attachment 130576 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=130576&action=review >> Source/WebCore/html/HTMLDetailsElement.cpp:163 >> + return 1 == shadowTree()->size(); > > I don't understand. Why it's okay for selection to be inside the light dom when there are more than 1 shadow trees? I don't understand either :) IMG, VIDEO, and AUDIO all have the content not distributed?
Hajime Morrita
Comment 7 2012-03-07 18:50:30 PST
OK, maybe we could have more robust way to do this...
Hajime Morrita
Comment 8 2012-03-12 04:13:42 PDT
Created attachment 131313 [details] Patch
Hajime Morrita
Comment 9 2012-03-12 04:16:05 PDT
Generalized the last version. The most naive approach would be actually traverse whole content and find possible caret position. But I don't want it because it doubles the traversal cost.
WebKit Review Bot
Comment 10 2012-03-12 05:24:23 PDT
Comment on attachment 131313 [details] Patch Attachment 131313 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/11939835 New failing tests: svg/text/text-path-01-b.svg svg/custom/use-clipped-hit.svg
WebKit Review Bot
Comment 11 2012-03-12 06:26:33 PDT
Comment on attachment 131313 [details] Patch Attachment 131313 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/11940856 New failing tests: svg/text/text-path-01-b.svg svg/custom/use-clipped-hit.svg
Note You need to log in before you can comment on or make changes to this bug.