WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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
Details
Formatted Diff
Diff
Patch
(15.26 KB, patch)
2015-03-23 13:49 PDT
,
Brent Fulgham
dino
: review+
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Brent Fulgham
Comment 1
2015-03-17 13:20:17 PDT
<
rdar://problem/20129494
>
Brent Fulgham
Comment 2
2015-03-17 15:59:15 PDT
Created
attachment 248881
[details]
Patch
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
Created
attachment 249261
[details]
Patch
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
Committed
r181879
: <
http://trac.webkit.org/changeset/181879
>
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.
Top of Page
Format For Printing
XML
Clone This Bug