MouseEvent.screenX / screenY should be 0 / 0 for simulated clicks. This is the behavior of Chrome and Firefox. However, WebKit computes actual screenX / screenY values which requires a synchronous IPC with the UI process. Demo: https://jsfiddle.net/7nc7ufkh/1/
https://jsfiddle.net/7nc7ufkh/3/ shows that clientX / clientY are also 0 for simulated clicks in Firefox and Chrome.
All coordinates (screenX, clientX, x, layerX, offsetX, pageX) are 0 in Firefox and Chrome for simulated clicks. However, they are all populated in Safari.
Seems to have been caused by <https://trac.webkit.org/changeset/160032>.
Created attachment 292048 [details] Patch
Comment on attachment 292048 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=292048&action=review > Source/WebCore/dom/SimulatedClick.cpp:70 > + } else if (AXObjectCache::accessibilityEnabled()) { > + // We apparently need coordinates when accessibility is enabled (see Bug 76677). > + // In other cases, the coordinates will be 0, which matches the behavior of Firefox and Chrome. > + // Note that the call to screenRect() causes a synchronous IPC with the UI process. This really doesn’t make sense. It’s OK to decide that accessibility-driven clicks need to include coordinates to be more like clicks done in other ways, but clicks created by JavaScript on the webpage don’t need them. We should not be checking globally whether accessibility is enabled. Instead we should have that code path pass a different argument or call a different function.
Created attachment 292049 [details] Patch
Created attachment 292052 [details] Patch
*** Bug 130301 has been marked as a duplicate of this bug. ***
Comment on attachment 292052 [details] Patch Clearing flags on attachment: 292052 Committed r207544: <http://trac.webkit.org/changeset/207544>
All reviewed patches have been landed. Closing bug.
Looks like a 4% progression on Speedometer.
Mass move bugs into the DOM component.