Open Bug 1471538 Opened 2 years ago Updated 2 years ago
.synthesize Mouse At Point() should only call ns IDOMWindow Utils .send Mouse Event() if there is a valid window handle
User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 Build ID: 20180530201719 Steps to reproduce: Initiated a mouse move during a selenium test run Actual results: Intermittently we receive this: Message: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMWindowUtils.sendMouseEvent]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://marionette/content/event.js :: event.synthesizeMouseAtPoint :: line 300" data: no] Expected results: Move shouldn't generate an exception
Status: UNCONFIRMED → NEW
Component: Untriaged → Marionette
Ever confirmed: true
Product: Firefox → Testing
As it looks like the problem always seem to appear for `mousemove`. Here one example with the values as the `sendMouseEvent()` method is called via DOMWindowUtils: ** [object String] "mousemove" ** left [object Number] 560 ** top [object Number] 95 ** button [object Number] 0 ** clickCount [object Number] 1 ** modifiers [object Number] 0 ** false [object Boolean] false ** pressure [object Number] 0 ** inputSource [object Number] 1 ** isDOMEventSynthesized [object Boolean] true ** isWidgetEventSynthesized [object Boolean] false ** buttons [object Number] 0 So there are 4 different places in that method where a failure like this could be raised. Olli, we would have to debug `nsContentUtils::SendMouseEvent()` for the problem as reported here. Sadly we cannot easily attach a debugger, so mind telling us what is the best way to add some logging to the following method? https://dxr.mozilla.org/mozilla-central/source/dom/base/nsContentUtils.cpp#8411 Thanks!
Here a link to the source of Marionette where the call fails: https://dxr.mozilla.org/mozilla-central/rev/681eb7dfa324dd50403c382888929ea8b8b11b00/testing/marionette/event.js#300
So, is the DOMWindowUtils object such that the window object it was created for is still open? In which process is the code running?
(In reply to Olli Pettay [:smaug] from comment #5) > So, is the DOMWindowUtils object such that the window object it was created > for is still open? I assume so, but hard to tell from the above information. Pete, would you please be so kind to also attach a geckodriver trace-level log on this bug? It would help me to further diagnose what Olli asked for. Thanks. > In which process is the code running? The failure here clearly happens in one of the framescripts Marionette loads into the content process.
(In reply to Olli Pettay [:smaug] from comment #5) > So, is the DOMWindowUtils object such that the window object it was created > for is still open? Yes, from the log I cannot see that the content window has been destroyed. But I asked Pete now to add an extra log line for `win.closed`. The problem seems to manifest when we call `sendMouseEvent` multiple times after each other in short intervals.
So it seems to be the case was because of a previous action chains call which performed a click, which performed a navigation. This then made the window invalid, causing the issue. In our code, we moved to a "real" click, but also had to add a delay. It appears that some kind of animation or something can sometimes (in our case) take upwards of 700ms. A 1 second timer had to be added after clicks which were known to create navigations.
Just to sum-up what happens here is: 1) the action chain contains a click event, which causes the document to navigate 2) a following mouse move event (split up in multiple move steps with a delay of 17ms in-between each of those) calls `nsIDOMWindowUtils.sendMouseEvent()`. One of those calls fails because it races with the currently happening navigation As such `event.synthesizeMouseAtPoint()` and maybe other methods in that module should check the window status the DOMWindowUtils have been created from first, before calling `sendMouseEvent()`. It should be enough to add a check for `win.closed`, and in case of a failure a `no such element` error has to be raised, because it is stale. Beside the above I wonder why our internal window reference hasn't been updated. Maybe that is even the problem here?
Priority: -- → P3
Summary: NS_ERROR_FAILURE during event.synthesizeMouseAtPoint → event.synthesizeMouseAtPoint() should only call nsIDOMWindowUtils.sendMouseEvent() if there is a valid window handle
You need to log in before you can comment on or make changes to this bug.