Bug 95204

Summary: Allow child-frame content in hit-tests.
Product: WebKit Reporter: Allan Sandfeld Jensen <allan.jensen>
Component: UI EventsAssignee: Allan Sandfeld Jensen <allan.jensen>
Status: RESOLVED FIXED    
Severity: Normal CC: dglazkov, eric, gustavo, jchaffraix, kevers, ojan.autocc, philn, rbyers, simon.fraser, tonikitoo, webkit.review.bot, wjmaclean, xan.lopez
Priority: P2    
Version: 420+   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on: 96908, 95685, 95720, 96830, 98139, 111217    
Bug Blocks: 94936    
Attachments:
Description Flags
Patch
none
Patch
none
Patch
none
Patch
none
Patch
none
Patch for landing
none
Patch
none
Patch
none
Patch
none
Patch
none
Patch
none
Patch
none
Patch jchaffraix: review+

Allan Sandfeld Jensen
Reported 2012-08-28 08:10:01 PDT
Content from child-frames is often needed in hit-tests. Currently EventHandler::hitTestResultAtPoint descends into any child-frames returned as the innerNode of a hit-test, and uses the cached localPoint value in HitTestResult to continue the hit-test where it stopped. This is problem on multiple levels for area-based hit-tests, since it only iterates into one frame and not all intersected frames, and does not handle any potential transformations to the area being hit-tested.
Attachments
Patch (31.80 KB, patch)
2012-08-28 08:48 PDT, Allan Sandfeld Jensen
no flags
Patch (53.49 KB, patch)
2012-08-29 05:43 PDT, Allan Sandfeld Jensen
no flags
Patch (56.63 KB, patch)
2012-08-29 06:47 PDT, Allan Sandfeld Jensen
no flags
Patch (60.15 KB, patch)
2012-09-03 03:15 PDT, Allan Sandfeld Jensen
no flags
Patch (39.22 KB, patch)
2012-09-03 08:17 PDT, Allan Sandfeld Jensen
no flags
Patch for landing (38.49 KB, patch)
2012-09-04 01:43 PDT, Allan Sandfeld Jensen
no flags
Patch (34.35 KB, patch)
2012-12-13 06:43 PST, Allan Sandfeld Jensen
no flags
Patch (35.89 KB, patch)
2012-12-13 07:30 PST, Allan Sandfeld Jensen
no flags
Patch (34.54 KB, patch)
2013-01-09 02:02 PST, Allan Sandfeld Jensen
no flags
Patch (36.12 KB, patch)
2013-01-09 06:04 PST, Allan Sandfeld Jensen
no flags
Patch (38.33 KB, patch)
2013-01-11 04:32 PST, Allan Sandfeld Jensen
no flags
Patch (28.92 KB, patch)
2013-02-15 03:36 PST, Allan Sandfeld Jensen
no flags
Patch (29.60 KB, patch)
2013-02-19 03:15 PST, Allan Sandfeld Jensen
jchaffraix: review+
Allan Sandfeld Jensen
Comment 1 2012-08-28 08:48:46 PDT
Allan Sandfeld Jensen
Comment 2 2012-08-28 08:55:28 PDT
The patch needs a few test-cases to be complete, and I want feed-back on the following two of the new flags ChildFrameHitTest and TestChildFrameScrollBars. The first flag was necessary beause RenderLayer::hitTest always claims the hit is fully inside if it thinks it is the RootLayer. And alternative to adding that flag, could be to change the check for isRootLayer, to something that checks if it is the root layer of the top frame. The second flag was only necessary to remain consistant with the old behavior of hitTestResultAtPoint. I actually don't see any good reason not to hit-test the frame scroll-bars. The scroll-bars already have a value to indicate if they participate in hit-testing or not.
Kevin Ellis
Comment 3 2012-08-28 10:58:24 PDT
How with this patch impact performance on point based hit tests?
Allan Sandfeld Jensen
Comment 4 2012-08-28 11:08:58 PDT
(In reply to comment #3) > How with this patch impact performance on point based hit tests? It shouldn't have any effect on point based tests. They already descended into child frames, it just used to happen in EventHandler::hitTestResultAtPoint, and now it is handled in RenderFrameBase::nodeAtPoint. The returned hit-test result is not completely identical, but I think this one is more correct, but nothing depends on the difference.
Allan Sandfeld Jensen
Comment 5 2012-08-29 02:29:33 PDT
*** Bug 94936 has been marked as a duplicate of this bug. ***
Allan Sandfeld Jensen
Comment 6 2012-08-29 05:43:52 PDT
Created attachment 161201 [details] Patch Added two tests, and made allow-child-frame content an option to nodesFromRect
Build Bot
Comment 7 2012-08-29 06:29:18 PDT
Build Bot
Comment 8 2012-08-29 06:33:12 PDT
Allan Sandfeld Jensen
Comment 9 2012-08-29 06:47:18 PDT
Created attachment 161215 [details] Patch Updated lists of exported symbols
Build Bot
Comment 10 2012-08-29 07:31:22 PDT
WebKit Review Bot
Comment 11 2012-08-29 14:40:23 PDT
Comment on attachment 161215 [details] Patch Attachment 161215 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/13695343
Allan Sandfeld Jensen
Comment 12 2012-09-03 03:15:17 PDT
WebKit Review Bot
Comment 13 2012-09-03 04:30:55 PDT
Comment on attachment 161891 [details] Patch Attachment 161891 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/13729836 New failing tests: touchadjustment/iframe-boundary.html
Allan Sandfeld Jensen
Comment 14 2012-09-03 06:45:51 PDT
Comment on attachment 161891 [details] Patch I am splitting part of the patch out into bug #95685. The patch will need a rebase once that patch lands.
Allan Sandfeld Jensen
Comment 15 2012-09-03 08:17:14 PDT
Created attachment 161932 [details] Patch Rebased and slightly modified the test so it hopefully gives identical results on more platforms
Antonio Gomes
Comment 16 2012-09-03 08:30:40 PDT
Comment on attachment 161932 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=161932&action=review r=me > Source/WebCore/dom/Document.cpp:1387 > +PassRefPtr<NodeList> Document::nodesFromRect(int centerX, int centerY, unsigned topPadding, unsigned rightPadding, unsigned bottomPadding, unsigned leftPadding, bool ignoreClipping, bool allowShadowContent, bool allowChildFrameContent) const it is getting time for us to improve this API. This bunch of books are getting out of control. We could even pass a HitTestRequest to it? > Source/WebCore/rendering/RenderLayer.cpp:3452 > + if (Frame *frame = renderer() ? renderer()->frame() : 0) > + return (frame == frame->page()->mainFrame()); > + return false; lets do if (!renderer()) return false; return blah == bleh ? a : b; > Source/WebCore/rendering/RenderLayer.h:376 > + bool isRootLayerOfMainFrame() const; should be private?
Antonio Gomes
Comment 17 2012-09-03 08:31:38 PDT
(In reply to comment #16) > (From update of attachment 161932 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=161932&action=review > > r=me > > > Source/WebCore/dom/Document.cpp:1387 > > +PassRefPtr<NodeList> Document::nodesFromRect(int centerX, int centerY, unsigned topPadding, unsigned rightPadding, unsigned bottomPadding, unsigned leftPadding, bool ignoreClipping, bool allowShadowContent, bool allowChildFrameContent) const > > it is getting time for us to improve this API. This bunch of books are getting out of control. We could even pass a HitTestRequest to it? bools*
Allan Sandfeld Jensen
Comment 18 2012-09-03 08:38:51 PDT
(In reply to comment #16) > (From update of attachment 161932 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=161932&action=review > > r=me > > > Source/WebCore/dom/Document.cpp:1387 > > +PassRefPtr<NodeList> Document::nodesFromRect(int centerX, int centerY, unsigned topPadding, unsigned rightPadding, unsigned bottomPadding, unsigned leftPadding, bool ignoreClipping, bool allowShadowContent, bool allowChildFrameContent) const > > it is getting time for us to improve this API. This bunch of books are getting out of control. We could even pass a HitTestRequest to it? > Sounds like a good idea. > > Source/WebCore/rendering/RenderLayer.cpp:3452 > > + if (Frame *frame = renderer() ? renderer()->frame() : 0) > > + return (frame == frame->page()->mainFrame()); > > + return false; > > lets do > > if (!renderer()) > return false; > > return blah == bleh ? a : b; > > > Source/WebCore/rendering/RenderLayer.h:376 > > + bool isRootLayerOfMainFrame() const; > > should be private? It appears that new part in the most recent patch is going to cause a fail on fast/events/drag-outside-window.html, so I will need to rethink it. Probably going back to the extra hit-test-request flag used in the first patch.
Allan Sandfeld Jensen
Comment 19 2012-09-03 08:40:58 PDT
(In reply to comment #18) > (In reply to comment #16) > > (From update of attachment 161932 [details] [details]) > > View in context: https://bugs.webkit.org/attachment.cgi?id=161932&action=review > > > > r=me > > > > > Source/WebCore/dom/Document.cpp:1387 > > > +PassRefPtr<NodeList> Document::nodesFromRect(int centerX, int centerY, unsigned topPadding, unsigned rightPadding, unsigned bottomPadding, unsigned leftPadding, bool ignoreClipping, bool allowShadowContent, bool allowChildFrameContent) const > > > > it is getting time for us to improve this API. This bunch of books are getting out of control. We could even pass a HitTestRequest to it? > > > Sounds like a good idea. > Btw, the same applies for EventHandler::hitTestResultAtPoint. All the bool arguments could be send as part of the HitTestRequest flag it is also getting.
WebKit Review Bot
Comment 20 2012-09-03 10:50:42 PDT
Comment on attachment 161932 [details] Patch Attachment 161932 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/13744206 New failing tests: fast/events/autoscroll-should-not-stop-on-keypress.html fast/events/drag-outside-window.html
Allan Sandfeld Jensen
Comment 21 2012-09-04 01:43:55 PDT
Created attachment 161988 [details] Patch for landing
WebKit Review Bot
Comment 22 2012-09-04 04:56:23 PDT
Comment on attachment 161988 [details] Patch for landing Clearing flags on attachment: 161988 Committed r127457: <http://trac.webkit.org/changeset/127457>
WebKit Review Bot
Comment 23 2012-09-04 04:56:28 PDT
All reviewed patches have been landed. Closing bug.
Julien Chaffraix
Comment 24 2012-09-13 07:43:26 PDT
This change caused bug 96593.
Allan Sandfeld Jensen
Comment 25 2012-09-13 07:56:40 PDT
(In reply to comment #24) > This change caused bug 96593. That makes sense. Check if the patch uploaded to bug #96541 fixes the issue.
Julien Chaffraix
Comment 26 2012-09-14 14:06:09 PDT
After getting several serious regressions on Chromium (like context menus popping at the wrong position when clicking inside frames), Antonio and myself decided to revert this change along with the follow-up fixes. The change is probably good but you are changing the behavior of a core hit-testing methods which will impact all ports. There is way too much code to cover and breakages are expected so notifying people about it would have been a good first step.
Allan Sandfeld Jensen
Comment 27 2012-09-14 15:08:43 PDT
(In reply to comment #26) > After getting several serious regressions on Chromium (like context menus popping at the wrong position when clicking inside frames), Antonio and myself decided to revert this change along with the follow-up fixes. > > The change is probably good but you are changing the behavior of a core hit-testing methods which will impact all ports. There is way too much code to cover and breakages are expected so notifying people about it would have been a good first step. I understand this point. I have a handful of ideas for how to avoid the issues, but I guess I could also integrate that in a later patch. The worst part about this though, is that these issues appear in the ports instead of WebCore, making new test cases to test for the observed issues (probably) impossible. For instance they don't appear on Mac, Qt, EFL or GTK.
Julien Chaffraix
Comment 28 2012-09-14 15:50:21 PDT
(In reply to comment #27) > (In reply to comment #26) > > After getting several serious regressions on Chromium (like context menus popping at the wrong position when clicking inside frames), Antonio and myself decided to revert this change along with the follow-up fixes. > > > > The change is probably good but you are changing the behavior of a core hit-testing methods which will impact all ports. There is way too much code to cover and breakages are expected so notifying people about it would have been a good first step. > > I understand this point. I have a handful of ideas for how to avoid the issues, but I guess I could also integrate that in a later patch. The worst part about this though, is that these issues appear in the ports instead of WebCore, making new test cases to test for the observed issues (probably) impossible. For instance they don't appear on Mac, Qt, EFL or GTK. A deprecation of the old behavior and opt-in into the new one would have been better as it would have avoided the situation where all the platforms get broken unless investigated & fixed. I am happy to help you get something along those lines landed.
Julien Chaffraix
Comment 29 2012-09-14 19:17:28 PDT
Reopening as the fix was revert in http://trac.webkit.org/changeset/128677
Allan Sandfeld Jensen
Comment 30 2012-12-13 06:43:09 PST
Created attachment 179265 [details] Patch Rebased and refactored to work with the changes in HitTestResult
Build Bot
Comment 31 2012-12-13 07:19:19 PST
Allan Sandfeld Jensen
Comment 32 2012-12-13 07:30:27 PST
Created attachment 179272 [details] Patch Fix exported symbols in WK2 for Windows
Simon Fraser (smfr)
Comment 33 2012-12-13 08:46:04 PST
Comment on attachment 179272 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=179272&action=review > Source/WebCore/dom/Document.h:384 > + PassRefPtr<NodeList> nodesFromRect(int centerX, int centerY, > + unsigned topPadding, unsigned rightPadding, unsigned bottomPadding, unsigned leftPadding, > + bool ignoreClipping, bool allowShadowContent, bool allowChildFrameContent = false) const; I think it would be much nicer and more readable to change all these bools into a set of bitflags.
Antonio Gomes
Comment 34 2012-12-13 09:14:40 PST
(In reply to comment #33) > (From update of attachment 179272 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=179272&action=review > > > Source/WebCore/dom/Document.h:384 > > + PassRefPtr<NodeList> nodesFromRect(int centerX, int centerY, > > + unsigned topPadding, unsigned rightPadding, unsigned bottomPadding, unsigned leftPadding, > > + bool ignoreClipping, bool allowShadowContent, bool allowChildFrameContent = false) const; > > I think it would be much nicer and more readable to change all these bools into a set of bitflags. I suggested the same. See bug 95720.
WebKit Review Bot
Comment 35 2012-12-13 10:07:44 PST
Comment on attachment 179272 [details] Patch Attachment 179272 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/15312304 New failing tests: fast/events/touch/touch-inside-iframe-scrolled.html
WebKit Review Bot
Comment 36 2012-12-13 11:12:18 PST
Comment on attachment 179272 [details] Patch Attachment 179272 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/15312324 New failing tests: fast/events/touch/touch-inside-iframe-scrolled.html
Allan Sandfeld Jensen
Comment 37 2012-12-13 15:27:37 PST
(In reply to comment #33) > (From update of attachment 179272 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=179272&action=review > > > Source/WebCore/dom/Document.h:384 > > + PassRefPtr<NodeList> nodesFromRect(int centerX, int centerY, > > + unsigned topPadding, unsigned rightPadding, unsigned bottomPadding, unsigned leftPadding, > > + bool ignoreClipping, bool allowShadowContent, bool allowChildFrameContent = false) const; > > I think it would be much nicer and more readable to change all these bools into a set of bitflags. I agree, I have patch to do that (I think it was even applied and rolled back with this one). I prefer to keep the patches separate though, because the refactoring of the bools to bitflags interferes a lot more with the ports.
Antonio Gomes
Comment 38 2012-12-14 05:18:35 PST
Comment on attachment 179272 [details] Patch Looks generally good. One question:
Allan Sandfeld Jensen
Comment 39 2013-01-09 02:02:51 PST
Created attachment 181880 [details] Patch Rebased and fix fast/events/touch/touch-inside-iframe-scrolled.html
Eric Seidel (no email)
Comment 40 2013-01-09 02:16:35 PST
Comment on attachment 181880 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=181880&action=review > Source/WebCore/dom/Document.h:385 > + PassRefPtr<NodeList> nodesFromRect(int centerX, int centerY, > + unsigned topPadding, unsigned rightPadding, unsigned bottomPadding, unsigned leftPadding, > + bool ignoreClipping, bool allowShadowContent, bool allowChildFrameContent = false) const; This is possibly the worst function signature ever. (Not suggesting that's your fault!) bools and split-coordinates as integers. Good times. :(
Build Bot
Comment 41 2013-01-09 02:33:31 PST
Allan Sandfeld Jensen
Comment 42 2013-01-09 05:55:45 PST
(In reply to comment #40) > (From update of attachment 181880 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=181880&action=review > > > Source/WebCore/dom/Document.h:385 > > + PassRefPtr<NodeList> nodesFromRect(int centerX, int centerY, > > + unsigned topPadding, unsigned rightPadding, unsigned bottomPadding, unsigned leftPadding, > > + bool ignoreClipping, bool allowShadowContent, bool allowChildFrameContent = false) const; > > This is possibly the worst function signature ever. (Not suggesting that's your fault!) bools and split-coordinates as integers. Good times. :( That is bug #95720. Hopefully I will get back to that when this one lands for good.
Allan Sandfeld Jensen
Comment 43 2013-01-09 06:04:56 PST
Created attachment 181904 [details] Patch Update the windows symbols in the new place they reside.
Build Bot
Comment 44 2013-01-09 06:37:08 PST
Simon Fraser (smfr)
Comment 45 2013-01-09 09:14:49 PST
Comment on attachment 181904 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=181904&action=review > Source/WebCore/ChangeLog:10 > + Refactors how EventHandler::hitTestResultAtPoint handles child-frame content, > + it is now handled by the hit test itself controlled by the AllowChildFrameContent > + flag in HitTestRequest. What's the justification for this? Some more context would be good. > Source/WebCore/dom/Document.cpp:1381 > +PassRefPtr<NodeList> Document::nodesFromRect(int centerX, int centerY, unsigned topPadding, unsigned rightPadding, unsigned bottomPadding, unsigned leftPadding, bool ignoreClipping, bool allowShadowContent, bool allowChildFrameContent) const Can we change these bools to bitflags? That would make things easier to read.
Allan Sandfeld Jensen
Comment 46 2013-01-09 10:13:52 PST
(In reply to comment #45) > (From update of attachment 181904 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=181904&action=review > > > Source/WebCore/ChangeLog:10 > > + Refactors how EventHandler::hitTestResultAtPoint handles child-frame content, > > + it is now handled by the hit test itself controlled by the AllowChildFrameContent > > + flag in HitTestRequest. > > What's the justification for this? Some more context would be good. > I can try to improve the ChangeLog. The goal is to return elements from all frames when doing an area-based hit-test. Currently we only return the elements in the inner most iframe containing the center point of the area. This will especially improve touch adjustment in areas near frame borders. > > Source/WebCore/dom/Document.cpp:1381 > > +PassRefPtr<NodeList> Document::nodesFromRect(int centerX, int centerY, unsigned topPadding, unsigned rightPadding, unsigned bottomPadding, unsigned leftPadding, bool ignoreClipping, bool allowShadowContent, bool allowChildFrameContent) const > > Can we change these bools to bitflags? That would make things easier to read. Yes, that is bug #95720.
Antonio Gomes
Comment 47 2013-01-09 10:33:07 PST
(In reply to comment #46) > (In reply to comment #45) > > (From update of attachment 181904 [details] [details]) > > View in context: https://bugs.webkit.org/attachment.cgi?id=181904&action=review > > > > > Source/WebCore/ChangeLog:10 > > > + Refactors how EventHandler::hitTestResultAtPoint handles child-frame content, > > > + it is now handled by the hit test itself controlled by the AllowChildFrameContent > > > + flag in HitTestRequest. > > > > What's the justification for this? Some more context would be good. > > > I can try to improve the ChangeLog. The goal is to return elements from all frames when doing an area-based hit-test. Currently we only return the elements in the inner most iframe containing the center point of the area. This will especially improve touch adjustment in areas near frame borders. This is important otherwise ports have to do recursive calls like http://trac.webkit.org/browser/trunk/Source/WebKit/blackberry/WebKitSupport/FatFingers.cpp#L338
Antonio Gomes
Comment 48 2013-01-09 12:43:41 PST
Comment on attachment 181904 [details] Patch Codewise, it looks relatively good to me. Simon, Julien?
Allan Sandfeld Jensen
Comment 49 2013-01-11 04:32:31 PST
Created attachment 182320 [details] Patch Update all four copies of the symbol in the win build-file, and explain the benfit of the change in the ChangeLog.
Allan Sandfeld Jensen
Comment 50 2013-01-16 03:13:58 PST
Ping? The EWS is all green and there seems to be no more objections, except the one covered by bug #95720.
Julien Chaffraix
Comment 51 2013-01-24 16:40:20 PST
Comment on attachment 182320 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=182320&action=review Sorry for the delay. The change looks OK with some comments. > Source/WebCore/dom/Document.cpp:1382 > -PassRefPtr<NodeList> Document::nodesFromRect(int centerX, int centerY, unsigned topPadding, unsigned rightPadding, unsigned bottomPadding, unsigned leftPadding, bool ignoreClipping, bool allowShadowContent) const > +PassRefPtr<NodeList> Document::nodesFromRect(int centerX, int centerY, unsigned topPadding, unsigned rightPadding, unsigned bottomPadding, unsigned leftPadding, bool ignoreClipping, bool allowShadowContent, bool allowChildFrameContent) const Antonio pointed out that we should improve this API. I would rather if we did that *before* this change than after, that would avoid API churn (especially since you have to touch several exported symbols). Here using a flag would free you from future change in the API. On top of that, you are already doing a boolean <-> flag conversion below. Postponing migrating Internals' nodeFromPoint is fine, especially since that would involve touching some tests. > Source/WebCore/page/EventHandler.cpp:1024 > + // hitTestResultAtPoint always handle child frame content. A 'why' comment would be better here. > Source/WebCore/page/TouchAdjustment.cpp:228 > + Node* ancestor = node->parentOrHostNode(); > + if (ancestor) This goes on one line. > Source/WebCore/page/TouchAdjustment.cpp:231 > + if (node->isDocumentNode()) > + return static_cast<const Document*>(node)->ownerElement(); Would be nice to have a toDocument helper function. > Source/WebCore/rendering/HitTestResult.h:134 > + void setPointInInnerNodeFrame(const LayoutPoint& point) { m_pointInInnerNodeFrame = point; } Since nobody uses this function, we should probably postpone adding it no? > Source/WebCore/rendering/RenderFrameBase.cpp:111 > + if (request.allowsChildFrameContent()) { We usually prefer early returns to avoid nested code.
Allan Sandfeld Jensen
Comment 52 2013-02-15 03:36:56 PST
Created attachment 188526 [details] Patch Modified according to reviewer feedback and rebased to apply on top of the landed patch for bug #95720
Julien Chaffraix
Comment 53 2013-02-18 09:29:39 PST
Comment on attachment 188526 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=188526&action=review > Source/WebCore/ChangeLog:24 > + (Document): Let's remove these empty entries and have the ChangeLog entries filled too. > Source/WebCore/page/TouchAdjustment.cpp:225 > +static inline Node* parentShadowHostOrOwner(const Node* node) An explanation about why we need this new function would be nice. > Source/WebCore/rendering/RenderFrameBase.cpp:112 > + FrameView* childFrameView = static_cast<FrameView*>(widget()); Some comments: * The old code would check result.isOverWidget(), why is this not needed anymore? * The old code was checking that widget() was a FrameView before doing the cast. I would much prefer if we at least ASSERT'ed that (probably ASSERT_WITH_SECURITY_IMPLICATION).
Allan Sandfeld Jensen
Comment 54 2013-02-18 09:44:11 PST
(In reply to comment #53) > (From update of attachment 188526 [details]) > > Source/WebCore/page/TouchAdjustment.cpp:225 > > +static inline Node* parentShadowHostOrOwner(const Node* node) > > An explanation about why we need this new function would be nice. > Because we want to travel up the event-tree, so that the inner most event receiver gets the event. If this change was not made, frames would compete with their content for touch-adjustment because they are always focusable, but since an unhandled event to their content would get to the frame anyway, the frame should be ignored when their content is a candidate for touch-adjustment. This algorithm is already applied to any event handling container versus it children, the previously used method parentOrshadowHost was just stopping at frame boundaries. > > Source/WebCore/rendering/RenderFrameBase.cpp:112 > > + FrameView* childFrameView = static_cast<FrameView*>(widget()); > > Some comments: > * The old code would check result.isOverWidget(), why is this not needed anymore? The old code was trying to figure out if the hit-test had stopped at a RenderFrameBase object, so it could continue the hit-test inside that frame. Since the code has now been moved to RenderFrameBase, we can now continue immediately and do no longer need to figure out later if we were over a widget and if that widget was a frame. > * The old code was checking that widget() was a FrameView before doing the cast. I would much prefer if we at least ASSERT'ed that (probably ASSERT_WITH_SECURITY_IMPLICATION). I will do that.
Allan Sandfeld Jensen
Comment 55 2013-02-19 03:15:33 PST
Antonio Gomes
Comment 56 2013-02-19 04:19:01 PST
(In reply to comment #55) > Created an attachment (id=189041) [details] > Patch Looks good to me.
Julien Chaffraix
Comment 57 2013-02-21 20:36:17 PST
Comment on attachment 189041 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=189041&action=review r=me > Source/WebCore/rendering/RenderFrameBase.cpp:112 > + FrameView* childFrameView = static_cast<FrameView*>(widget()); I don't like a static_cast without any safety checks so please add (already mentioned in the previous review): ASSERT_WITH_SECURITY_IMPLICATION(widget()->isFrameView());
Allan Sandfeld Jensen
Comment 58 2013-02-22 06:48:42 PST
Note You need to log in before you can comment on or make changes to this bug.