Bug 5829

Summary: REGRESSION: cursor tracking and hit testing in scrollable block don't take borders into account
Product: WebKit Reporter: mitz
Component: Layout and RenderingAssignee: Beth Dakin <bdakin>
Status: VERIFIED FIXED    
Severity: Normal CC: bdakin, vicki
Priority: P1    
Version: 420+   
Hardware: Mac   
OS: OS X 10.4   
Attachments:
Description Flags
testcase
none
don't add left and bottom borders when hit-testing mjs: review+

Description mitz 2005-11-25 14:31:52 PST
Summary: cursor tracking and hit-testing for controls seem to be off by the width of the left/bottom 
border of a block that has overflow:auto or scroll.

To reproduce: open the testcase. Things to note:
1) the end of the scrollbar near the red square does not respond to clicking or dragging
2) clicking in the green rect near the edge of the scroll bar results in the following error in the console 
(if running a debug build): ERROR: KHTML says we hit a RenderWidget, but AppKit doesn't agree we hit 
the corresponding NSView
3) places where the cursor changes between arrow and I-beam along the line "Choose one: <option> 
from the pop-up"
4) places where the pop-up responds to clicks and places where clicking results in the above error
Comment 1 mitz 2005-11-25 14:32:51 PST
Created attachment 4800 [details]
testcase
Comment 2 mitz 2005-11-25 15:10:26 PST
I suspect that this is a regression from the fix for <rdar://problem/3885711> (bug 4047). In particular, 
the changes to RenderLayer::hitTestLayer which introduced borderLeft() and borderBottom() there.
Comment 3 mitz 2005-11-25 15:21:43 PST
Created attachment 4801 [details]
don't add left and bottom borders when hit-testing
Comment 4 mitz 2005-11-25 15:28:04 PST
Comment on attachment 4801 [details]
don't add left and bottom borders when hit-testing

I checked that this doesn't affect the testcase for bug 4047.
Comment 5 Maciej Stachowiak 2005-11-25 22:27:57 PST
Comment on attachment 4801 [details]
don't add left and bottom borders when hit-testing

r=me
Comment 6 Eric Seidel (no email) 2005-11-26 16:47:39 PST
Is there any way we could make a test case for this?
Comment 7 Eric Seidel (no email) 2005-11-26 16:49:21 PST
A DumpRenderTree test case, that is.  We have support for moving the mouse... There is probably a way to 
get the current cursor from JavaScript, if not, we could add that functionality to DumpRenderTree's 
layoutTestController
Comment 8 Darin Adler 2005-11-29 09:39:07 PST
I don't think it's easy to add querying the cursor to DumpRenderTree -- the OS doesn't even have a good 
way to inspect the current cursor.

But we can make a test that relies on hit testing rather than the cursor.
Comment 9 Vicki Murley 2005-11-29 11:49:21 PST
I committed this change.  I added the attached test case to the manual tests directory until we can find a 
better solution.
Comment 10 mitz 2005-12-18 08:26:02 PST
I should have made a more extensive testcase -- this is still (or has become) broken in certain conditions. 
I am going to file a new bug.