RESOLVED FIXED Bug 82163
Scrollable plugins not registered properly in ScrollingCoordinator
https://bugs.webkit.org/show_bug.cgi?id=82163
Summary Scrollable plugins not registered properly in ScrollingCoordinator
Nat Duca
Reported 2012-03-25 19:36:29 PDT
With threadeded compositing on, we process mousewheels on the impl thread. So, mouse scrolling never reaches the PDF plugin. ~cries~ To reproduce chrome --force-compositing-mode --enable-threaded-compositing --show-composited-layer-borders --register-pepper-plugins="/opt/google/chrome/libpdf.so;application/pdf" Then go to here: http://www.corp.google.com/~pavanv/no_crawl/pdf-samples/flatform.pdf If you dont have these applied, the screen wont update (although the scrolls will behave incorrectly): https://bugs.webkit.org/show_bug.cgi?id=82154 http://codereview.chromium.org/9856005/
Attachments
Patch (1.87 KB, patch)
2012-03-26 10:37 PDT, James Robinson
no flags
Patch (11.04 KB, patch)
2012-03-26 11:40 PDT, James Robinson
no flags
Patch (5.75 KB, patch)
2012-03-26 12:32 PDT, James Robinson
no flags
Patch (12.63 KB, patch)
2012-03-26 13:36 PDT, James Robinson
no flags
James Robinson
Comment 1 2012-03-26 10:13:14 PDT
Plugins are PluginViewBases, which are Widgets and thus scroll, but they aren't WebCore::ScrollableAreas so the computeNonFastScrollableRegion() test in ScrollingCoordinator ignores them. The fix is to check for scrollable plugins when iterating over Widgets.
James Robinson
Comment 2 2012-03-26 10:37:19 PDT
James Robinson
Comment 3 2012-03-26 10:40:03 PDT
This appears to work - any ideas on how to test? I was thinking of adding a DRT hook to dump the nonFastScrollableRegion as text on somewhere.
James Robinson
Comment 4 2012-03-26 11:40:00 PDT
Philippe Normand
Comment 5 2012-03-26 11:56:59 PDT
Build Bot
Comment 6 2012-03-26 12:07:07 PDT
Anders Carlsson
Comment 7 2012-03-26 12:11:51 PDT
Comment on attachment 133844 [details] Patch I don't really like the idea of making all plug-ins be non-scrollable. Can we add a member function to PluginViewBase to let subclasses control this instead? (I'm really tempted to not send wheel events to some plug-ins that we know never handle them correctly)
James Robinson
Comment 8 2012-03-26 12:24:15 PDT
(In reply to comment #7) > (From update of attachment 133844 [details]) > I don't really like the idea of making all plug-ins be non-scrollable. Can we add a member function to PluginViewBase to let subclasses control this instead? (I'm really tempted to not send wheel events to some plug-ins that we know never handle them correctly) I can do that, but then it means I can't make a layout test (since I don't know how to instantiate a plugin that will hook up to the correct subclass).
Build Bot
Comment 9 2012-03-26 12:30:15 PDT
James Robinson
Comment 10 2012-03-26 12:32:36 PDT
James Robinson
Comment 11 2012-03-26 12:33:21 PDT
How about this? Other PluginViewBase subclasses would have to register themselves in the proper way, but I'm not familiar with how they all work.
Anders Carlsson
Comment 12 2012-03-26 12:36:48 PDT
Comment on attachment 133866 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=133866&action=review > Source/WebCore/page/scrolling/ScrollingCoordinator.cpp:142 > +Region ScrollingCoordinator::nonFastScrollableRegion() > +{ > + return computeNonFastScrollableRegion(m_page->mainFrame()->view()); > +} This change seems unrelated. > Source/WebCore/page/scrolling/ScrollingCoordinator.h:118 > + Region nonFastScrollableRegion(); Ditto. > Source/WebCore/plugins/PluginViewBase.h:56 > + virtual bool scrollable() { return false; } I think this should be called wantsWheelEvents instead, since a plug-in may want wheel events without being scrollable.
James Robinson
Comment 13 2012-03-26 12:43:29 PDT
James Robinson
Comment 14 2012-03-26 13:33:10 PDT
Reopening since this doesn't properly handle a plugin becoming scrollable and could be done in a more straightforward way.
James Robinson
Comment 15 2012-03-26 13:36:34 PDT
James Robinson
Comment 16 2012-03-26 16:12:43 PDT
*** Bug 82164 has been marked as a duplicate of this bug. ***
WebKit Review Bot
Comment 17 2012-03-27 15:24:51 PDT
Comment on attachment 133880 [details] Patch Clearing flags on attachment: 133880 Committed r112325: <http://trac.webkit.org/changeset/112325>
WebKit Review Bot
Comment 18 2012-03-27 15:24:59 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.