RESOLVED FIXED 108848
Disable autoscrolling the main frame if main frame scrolling is disabled 
https://bugs.webkit.org/show_bug.cgi?id=108848
Summary Disable autoscrolling the main frame if main frame scrolling is disabled
Tim Horton
Reported 2013-02-04 12:26:55 PST
If main frame scrolling is disabled, you can still cause the main frame to scroll via autoscrolling (drag selection, etc.). This seems wrong. <rdar://problem/13004059>
Attachments
patch (1.25 KB, patch)
2013-02-04 12:28 PST, Tim Horton 		simon.fraser: review+
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Tim Horton
Comment 1 2013-02-04 12:28:19 PST
Created attachment 186435 [details] patch
Tim Horton
Comment 2 2013-02-04 12:32:17 PST
http://trac.webkit.org/changeset/141792
Darin Adler
Comment 3 2013-02-04 13:13:39 PST
Comment on attachment 186435 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=186435&action=review > Source/WebCore/rendering/RenderBox.cpp:755 > + return page && page->mainFrame() == frame && frame->view()->isScrollable(); Can frame->view() ever be null? Can frame->view() every be a view that is currently hosting a different frame?
Tim Horton
Comment 4 2013-02-04 14:10:01 PST
(In reply to comment #3) > (From update of attachment 186435 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=186435&action=review > > > Source/WebCore/rendering/RenderBox.cpp:755 > > + return page && page->mainFrame() == frame && frame->view()->isScrollable(); > > Can frame->view() ever be null? Can frame->view() every be a view that is currently hosting a different frame? I don't think either of those things can be true while we're also dispatching events to the page (I just followed all of the callers and that's the only way we get here), though I could be wrong. That seems scary for other reasons, though.
Note You need to log in before you can comment on or make changes to this bug.