WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
Bug 64298
positionForPoint is broken when a block is positioned relatively inside the parent
https://bugs.webkit.org/show_bug.cgi?id=64298
Summary
positionForPoint is broken when a block is positioned relatively inside the p...
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
Details
demo 2
(843 bytes, text/html)
2011-07-11 14:52 PDT
,
Ryosuke Niwa
no flags
Details
fixes the bug
(8.05 KB, patch)
2011-07-11 16:16 PDT
,
Ryosuke Niwa
no flags
Details
Formatted Diff
Diff
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
Details
fixed the test
(8.05 KB, patch)
2011-07-11 16:37 PDT
,
Ryosuke Niwa
no flags
Details
Formatted Diff
Diff
Show Obsolete
(2)
View All
Add attachment
proposed patch, testcase, etc.
Ryosuke Niwa
Comment 1
2011-07-11 10:48:59 PDT
Created
attachment 100325
[details]
demo
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.
Top of Page
Format For Printing
XML
Clone This Bug