Bug 64298

Summary: positionForPoint is broken when a block is positioned relatively inside the parent
Product: WebKit Reporter: Ryosuke Niwa <rniwa>
Component: HTML EditingAssignee: Ryosuke Niwa <rniwa>
Status: RESOLVED FIXED    
Severity: Normal CC: dglazkov, eae, hyatt, leviw, mitz, simon.fraser, webkit.review.bot
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
demo
none
demo 2
none
fixes the bug
none
Archive of layout-test-results from ec2-cr-linux-03
none
fixed the test none

Ryosuke Niwa
Reported 2011-07-11 10:48:40 PDT
When a block has the style "position: relative; left: 50px; padding-bottom: 20px;", hit-testing on the left of this block is broken.
Attachments
demo (429 bytes, text/html)
2011-07-11 10:48 PDT, Ryosuke Niwa
no flags
demo 2 (843 bytes, text/html)
2011-07-11 14:52 PDT, Ryosuke Niwa
no flags
fixes the bug (8.05 KB, patch)
2011-07-11 16:16 PDT, Ryosuke Niwa
no flags
Archive of layout-test-results from ec2-cr-linux-03 (1.34 MB, application/zip)
2011-07-11 16:33 PDT, WebKit Review Bot
no flags
fixed the test (8.05 KB, patch)
2011-07-11 16:37 PDT, Ryosuke Niwa
no flags
Ryosuke Niwa
Comment 1 2011-07-11 10:48:59 PDT
Ryosuke Niwa
Comment 2 2011-07-11 13:38:30 PDT
The problem seems to be that RenderBox::location() is not updated for this node: (gdb) p child->showTreeForThis() BODY 0x107478e40 #text 0x10a818690 "\n" * DIV 0x10a80cec0 STYLE=position: relative; left: 50px; padding-bottom: 20px; border: solid 1px #text 0x10a8186f0 "\nClick on the left of this box. The caret is placed at a wrong location.\n" #text 0x10a818e80 "\n" DIV 0x10a8172d0 #text 0x10a826330 "Selected text:" CODE 0x10a819240 DIV 0x1074701e0 #text 0x107470510 "\n" SCRIPT 0x107470570 #text 0x107470790 "\n\nfunction update() {\n document.getElementById('log').textContent = window.getSelection().toString();\n}\n\n" #text 0x107472450 "\n\n\n" $7 = void (gdb) p child->location() $8 = { m_x = 0, m_y = 0 }
Ryosuke Niwa
Comment 3 2011-07-11 13:41:54 PDT
RenderView 0x107474fa8 #document 0x108056000 RenderBlock 0x107473cc8 HTML 0x107473350 RenderBody 0x10a817cb8 BODY 0x107478e40 * RenderBlock (relative positioned) 0x10a8120e8 DIV 0x10a80cec0 STYLE=position: relative; left: 50px; padding-bottom: 20px; border: solid 1px RenderText 0x10a8121b8 #text 0x10a8186f0 "\nClick on the left of this box. The caret is placed at a wrong location.\n" RenderBlock 0x10a819108 DIV 0x10a8172d0 RenderBlock (anonymous) 0x107470458 RenderText 0x10a8191d8 #text 0x10a826330 "Selected text:" RenderInline 0x1074700f8 CODE 0x10a819240 RenderBlock 0x107470318 DIV 0x1074701e0
Simon Fraser (smfr)
Comment 4 2011-07-11 14:45:02 PDT
I find it hard to believe that hit testing on all position:relative blocks is broken.
Ryosuke Niwa
Comment 5 2011-07-11 14:49:00 PDT
(In reply to comment #4) > I find it hard to believe that hit testing on all position:relative blocks is broken. It's broken when left or top is specified and the block is inside the parent.
Ryosuke Niwa
Comment 6 2011-07-11 14:52:14 PDT
Created attachment 100364 [details] demo 2 It's actually harder to find cases where hit-testing is working.
Simon Fraser (smfr)
Comment 7 2011-07-11 14:54:57 PDT
But it's not. I can select the text just fine. This is something about placing the caret.
Ryosuke Niwa
Comment 8 2011-07-11 14:59:00 PDT
(In reply to comment #7) > But it's not. I can select the text just fine. This is something about placing the caret. I can't select text properly in any of the boxes in "demo 2".
Simon Fraser (smfr)
Comment 9 2011-07-11 15:02:44 PDT
demo 2 works fine for me. Maybe there's a chromium issue?
Ryosuke Niwa
Comment 10 2011-07-11 15:07:46 PDT
(In reply to comment #9) > demo 2 works fine for me. Maybe there's a chromium issue? No, I'm using WebKit Nightly. To demonstrate this bug, you have to start your mouse drag outside of the dark border but inside the light border.
Ryosuke Niwa
Comment 11 2011-07-11 15:10:19 PDT
(In reply to comment #9) > demo 2 works fine for me. Maybe there's a chromium issue? For a future reference, I almost never use chromium port for testing.
Ryosuke Niwa
Comment 12 2011-07-11 16:16:24 PDT
Created attachment 100376 [details] fixes the bug
Ryosuke Niwa
Comment 13 2011-07-11 16:17:14 PDT
Simon, sorry about the confusing :( Hopefully this patch clarifies what needs to be fixed.
WebKit Review Bot
Comment 14 2011-07-11 16:33:25 PDT
Comment on attachment 100376 [details] fixes the bug Attachment 100376 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/9010628 New failing tests: fast/block/positioning/hittest-on-relative-positioned-children.html
WebKit Review Bot
Comment 15 2011-07-11 16:33:29 PDT
Created attachment 100380 [details] Archive of layout-test-results from ec2-cr-linux-03 The attached test failures were seen while running run-webkit-tests on the chromium-ews. Bot: ec2-cr-linux-03 Port: Chromium Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
Ryosuke Niwa
Comment 16 2011-07-11 16:37:47 PDT
Created attachment 100383 [details] fixed the test
Ryosuke Niwa
Comment 17 2011-07-11 18:10:36 PDT
Comment on attachment 100383 [details] fixed the test Clearing flags on attachment: 100383 Committed r90800: <http://trac.webkit.org/changeset/90800>
Ryosuke Niwa
Comment 18 2011-07-11 18:10:41 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.