We'd like to add support for dispatching a mouse event at an element's location. This is particularly needed in order to click moving elements.
Created attachment 194394 [details] Patch
The name "dispatchMouseEventAtElement" sounds odd, shouldn't it be "dispatchMouseEventToElement"?
(In reply to comment #2) > The name "dispatchMouseEventAtElement" sounds odd, shouldn't it be "dispatchMouseEventToElement"? It is a bit odd, although a bit more accurate. I'll change it though so as not to confuse users.
Comment on attachment 194394 [details] Patch Attachment 194394 [details] did not pass mac-ews (mac): Output: http://webkit-commit-queue.appspot.com/results/17202647 New failing tests: inspector-protocol/input/dispatchMouseEventAtElement-frames.html
Created attachment 194552 [details] Archive of layout-test-results from webkit-ews-06 The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: webkit-ews-06 Port: <class 'webkitpy.common.config.ports.MacPort'> Platform: Mac OS X 10.8.2
Comment on attachment 194394 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=194394&action=review > Source/WebCore/inspector/InspectorInputAgent.cpp:189 > + FloatRect localRect; Sounds like logic has been copied from somewhere. What if it changes?
(In reply to comment #6) > (From update of attachment 194394 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=194394&action=review > > > Source/WebCore/inspector/InspectorInputAgent.cpp:189 > > + FloatRect localRect; > > Sounds like logic has been copied from somewhere. What if it changes? This was inspired from the node highlighting that DevTools does (http://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/WebCore/inspector/InspectorOverlay.cpp&sq=package:chromium&type=cs&q=InspectorOverlay&l=121). However, it is different in several ways and is greatly simplified. For inline elements, we take the first line box instead of the bounding box of all the line boxes. For SVG elements, instead of getting all the quads, we just use the stroke bounding box. We also get the local rect first, so we can add the optional offsets before transforming and converting to the root view. It is simplified because unlike InspectorOverlay, we don't care about the margin, padding, or content boxes. Although at the surface both methods involve getting info from the renderer, their purposes are quite different and I don't think could benefit from any sharing as of now. Let me know if you disagree.
Created attachment 194570 [details] Patch
(In reply to comment #8) > Created an attachment (id=194570) [details] > Patch Changed name to dispatchMouseEventToElement. Fixed build when svg is disabled.
Comment on attachment 194570 [details] Patch Attachment 194570 [details] did not pass mac-ews (mac): Output: http://webkit-commit-queue.appspot.com/results/17306138 New failing tests: inspector-protocol/input/dispatchMouseEventToElement-frames.html
Created attachment 194710 [details] Archive of layout-test-results from webkit-ews-06 for mac-future The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: webkit-ews-06 Port: mac-future Platform: Mac OS X 10.8.2
Comment on attachment 194570 [details] Patch Attachment 194570 [details] did not pass mac-ews (mac): Output: http://webkit-commit-queue.appspot.com/results/17310001 New failing tests: inspector-protocol/input/dispatchMouseEventToElement-frames.html
Created attachment 194717 [details] Archive of layout-test-results from webkit-ews-01 for mac-future The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: webkit-ews-01 Port: mac-future Platform: Mac OS X 10.8.2
There are no use cases for this in the new inspector that i'm aware of. Closing until such a time when we know what this is for.