[chromium] Do not propagate touch-events to plugins unless they explicitly request for touch-events.
Created attachment 165808 [details] Patch
Comment on attachment 165808 [details] Patch Can we test this change? Perhaps using a Chromium unit test?
It seems to me that the patch is pretty simple and likely to be right as long as setIsAcceptingTouchEvents gets called when appropriate. Could we test for that somehow? (Perhaps in a different patch?)
Comment on attachment 165808 [details] Patch I mean, this patch is fine, but we really should be testing this stuff. We don't have very many plugin test, especially for PPAPI plugins. I suspect writing a test here is going to be a fair amount of work because I don't think we have an API-level testing framework for plugins. That's something we should add, but I feel mean blocking this two-line patch on creating that testing framework.
Comment on attachment 165808 [details] Patch Clearing flags on attachment: 165808 Committed r129674: <http://trac.webkit.org/changeset/129674>
All reviewed patches have been landed. Closing bug.
(In reply to comment #4) > (From update of attachment 165808 [details]) > I mean, this patch is fine, but we really should be testing this stuff. We don't have very many plugin test, especially for PPAPI plugins. I suspect writing a test here is going to be a fair amount of work because I don't think we have an API-level testing framework for plugins. That's something we should add, but I feel mean blocking this two-line patch on creating that testing framework. Thanks a lot! :) There are some ppapi-tests for this in chrome (ppapi/tests/test_input_event.cc), especially to make sure that calling setIsAcceptingTouchEvents() updates the state of the renderer and the corresponding host in the browser. However, we do not have any test at the moment to verify that a plugin does not receive any touch event at all unless it explicitly asks for it. I will look into adding a test like this. Thanks again for the quick review.