Summary: | Allow hit testing of page content without clipping to visible | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Adam Treat <manyoso> | ||||||||
Component: | Layout and Rendering | Assignee: | Nobody <webkit-unassigned> | ||||||||
Status: | RESOLVED FIXED | ||||||||||
Severity: | Normal | CC: | hyatt, simon.fraser, staikos, zimmermann | ||||||||
Priority: | P2 | ||||||||||
Version: | 528+ (Nightly build) | ||||||||||
Hardware: | Other | ||||||||||
OS: | All | ||||||||||
Attachments: |
|
Description
Adam Treat
2009-01-26 15:46:47 PST
Created attachment 27053 [details]
Don't clip to visible option
Implements the no clip option for hit tests.
Comment on attachment 27053 [details]
Don't clip to visible option
Patch looks fine, despite the fact that HitTestRequest is so ugly - it should really use enums as flags, instead of a wild series of booleans.
It would be great to get that fixed - but that's out of the scope for this patch. r=me.
Would you file a bug on HitTestRequest uglyness?
Are you thinking of an enum that can be OR'd together to generate the appropriate HitTestRequest? If so I'll come up with a patch... :) Reopened for layout test. Created attachment 27072 [details]
Fixes bug and also adds test
Added a test to qwebframe to guard against regression. I don't see a clean way of adding hit testing layout tests, but if anyone can think of a good way let me know.
Add Simon Add David Hyatt. (In reply to comment #3) > Are you thinking of an enum that can be OR'd together to generate the > appropriate HitTestRequest? If so I'll come up with a patch... :) > Yes, exactly. Would using elementFromPoint() be a better way to achieve what you are trying to do here? Maybe it clips to the viewport, and should not? At least it might give you a way to write a LayoutTest without adding code to tst_qwebframe. We could certainly modify elementFromPoint to use a HitTestRequest that does not clip to the viewport and thereby achieve a LayoutTest using JS, however this is a significant behavioral change that I was not sure is correct. The purpose of my patch is to make QWebFrame::hitTestContent method work correctly given its name and purpose. If you like I can modify 'elementFromPoint' accordingly, but are you sure this behavior change is correct and won't break JS DOM API standards? Actually elementFromPoint takes "client" (viewport) coords, so only finds things that are visible. Darn. Please update the patch to include a change to the WebCore.base.exp file for Mac, like: __ZN7WebCore12EventHandler14scrollOverflowENS_15ScrollDirectionENS_17ScrollGranu __ZN7WebCore12EventHandler20handleTextInputEventERKNS_6StringEPNS_5EventEbb -__ZN7WebCore12EventHandler20hitTestResultAtPointERKNS_8IntPointEb +__ZN7WebCore12EventHandler20hitTestResultAtPointERKNS_8IntPointEbb __ZN7WebCore12EventHandler20sendContextMenuEventERKNS_18PlatformMouseEventE and file another bug for the 'bool' cleanup. (In reply to comment #5) > I don't see a clean way > of adding hit testing layout tests, but if anyone can think of a good way let > me know. Generally you can make hit testing layout tests with eventSender, ensuring the correct element is hit. But perhaps you mean something different. This may be a fix that only affects some specific Qt API, not the behavior of the browser? I'm not really clear here on what the issue is. Darin, you have it right. The Qt API exposes a hitTestContent method that should return a valid HitTestResult regardless of the current viewport. As such, this patch is intended to fix the behavior of this one specific Qt API method. Created attachment 27075 [details]
Previous patches + mac export
Add the mac export line from Simon although I have no way to test if this is correct.
Committed with r40311. I'll open a bug report and make a patch for the bools next. |