RESOLVED FIXED 142789
Scroll latching logic can get stuck in 'scrollable="no"' iframes
https://bugs.webkit.org/show_bug.cgi?id=142789
Summary Scroll latching logic can get stuck in 'scrollable="no"' iframes
Brent Fulgham
Reported 2015-03-17 13:19:12 PDT
Certain advertisements on website are hosted inside iframes that have content areas that are larger than their on-page dimensions. The iframes are marked with 'scrollinge="no"' to prevent them from scrolling content. The latching logic didn't understand this case, and would only consider whether the iframe had scrollable content (which it does in this case), ignoring the 'scrolling="no"' declaration.
Attachments
Patch (3.25 KB, patch)
2015-03-17 15:59 PDT, Brent Fulgham
no flags
Patch (15.26 KB, patch)
2015-03-23 13:49 PDT, Brent Fulgham
dino: review+
Brent Fulgham
Comment 1 2015-03-17 13:20:17 PDT
Brent Fulgham
Comment 2 2015-03-17 15:59:15 PDT
Simon Fraser (smfr)
Comment 3 2015-03-17 16:11:52 PDT
Comment on attachment 248881 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=248881&action=review > Source/WebCore/page/mac/EventHandlerMac.mm:764 > + if (is<Element>(container)) { > + const auto& scrollingAttribute = downcast<Element>(container).fastGetAttribute(HTMLNames::scrollingAttr); > + if (scrollingAttribute == "no") > + return true; > + } It seems odd to do this without checking that the element is an iframe. I still think the rest of this function is confused about the relationship between the container node and the scrollable area.
Brent Fulgham
Comment 4 2015-03-23 13:49:54 PDT
Dean Jackson
Comment 5 2015-03-23 14:07:33 PDT
Comment on attachment 249261 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=249261&action=review > Source/WebCore/page/mac/EventHandlerMac.mm:948 > + // WebKit2 code path Did you mean to leave this in? > Source/WebCore/page/mac/EventHandlerMac.mm:964 > + // If the platform widget is handling the event, we always want to return false Another missing full stop. :)
Brent Fulgham
Comment 6 2015-03-23 15:53:05 PDT
Simon Fraser (smfr)
Comment 7 2015-03-25 21:27:15 PDT
Comment on attachment 249261 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=249261&action=review Why no tests? > Source/WebCore/ChangeLog:14 > + different. differently :) > Source/WebCore/page/mac/EventHandlerMac.mm:748 > + if (is<HTMLIFrameElement>(candidate)) > + continue; I think you could check this outside the loop, because you'll never hit children of a HTMLIFrameElement.
Tim Horton
Comment 8 2015-09-04 23:58:31 PDT
Comment on attachment 249261 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=249261&action=review > Source/WebCore/page/mac/EventHandlerMac.mm:-877 > - latchingState->setStartedGestureAtScrollLimit(scrolledToEdgeInDominantDirection(*scrollableContainer, *scrollableArea, wheelEvent.deltaX(), wheelEvent.deltaY())); You removed the only line of code that ever setStartedGestureAtScrollLimit to something non-false. I think this was an accident? Will continue investigating.
Note You need to log in before you can comment on or make changes to this bug.