VERIFIED FIXED 5829
REGRESSION: cursor tracking and hit testing in scrollable block don't take borders into account
https://bugs.webkit.org/show_bug.cgi?id=5829
Summary REGRESSION: cursor tracking and hit testing in scrollable block don't take bo...
mitz
Reported 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
Attachments
testcase (893 bytes, text/html)
2005-11-25 14:32 PST, mitz
no flags
don't add left and bottom borders when hit-testing (1.99 KB, patch)
2005-11-25 15:21 PST, mitz
mjs: review+
mitz
Comment 1 2005-11-25 14:32:51 PST
Created attachment 4800 [details] testcase
mitz
Comment 2 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.
mitz
Comment 3 2005-11-25 15:21:43 PST
Created attachment 4801 [details] don't add left and bottom borders when hit-testing
mitz
Comment 4 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.
Maciej Stachowiak
Comment 5 2005-11-25 22:27:57 PST
Comment on attachment 4801 [details] don't add left and bottom borders when hit-testing r=me
Eric Seidel (no email)
Comment 6 2005-11-26 16:47:39 PST
Is there any way we could make a test case for this?
Eric Seidel (no email)
Comment 7 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
Darin Adler
Comment 8 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.
Vicki Murley
Comment 9 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.
mitz
Comment 10 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.
Note You need to log in before you can comment on or make changes to this bug.