1471538 - event.synthesizeMouseAtPoint() should only call nsIDOMWindowUtils.sendMouseEvent() if there is a valid window handle

Status: NEW

(Remote Protocol :: Marionette, defect, P3)

Description

[Pete Savage]

Attachment: mozilla-bug-ff.txt

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

Comment 1

[Pete Savage]

Attachment: mozilla-bug-ff.txt

Comment 2

[Pete Savage]

Attachment: mozilla-bug-ff.txt

More examples

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+2] (away July 24th - August 16th)]

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!

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2] (away July 24th - August 16th)]

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

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

So, is the DOMWindowUtils object such that the window object it was created for is still open?

In which process is the code running?

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+2] (away July 24th - August 16th)]

(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.

Comment 7

[Pete Savage]

Attachment: ff60log.log

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+2] (away July 24th - August 16th)]

(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.

Comment 9

[Pete Savage]

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.

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+2] (away July 24th - August 16th)]

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?