Open Bug 1471538 Opened 2 years ago Updated 2 years ago

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

Categories

(Testing :: Marionette, defect, P3)

60 Branch
defect

Tracking

(Not tracked)

People

(Reporter: psavage, Unassigned)

Details

Attachments

(3 files, 1 obsolete file)

Attached file mozilla-bug-ff.txt (obsolete) —
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
Attachment #8988112 - Attachment is obsolete: true
Attached file mozilla-bug-ff.txt
Attached file mozilla-bug-ff.txt
More examples
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!
Flags: needinfo?(bugs)
So, is the DOMWindowUtils object such that the window object it was created for is still open?

In which process is the code running?
Flags: needinfo?(bugs)
(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.
Flags: needinfo?(psavage)
Attached file ff60log.log
Flags: needinfo?(psavage)
(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.