364508 - Need a way to synthesize events for automated testing

Status: RESOLVED FIXED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Neil Deakin]

For testing, there needs to be a way of sending low-level events at the widget level.

Comment 1

[Neil Deakin]

Attachment: simple implementation

Simple implementation which just implements two methods to send mouse and key events.

Not sure whether this should only be built with tests.

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Why are you targeting DOM nodes and not nsIWidgets? The latter would seem more logical...

Comment 3

[Neil Deakin]

(In reply to comment #2)
> Why are you targeting DOM nodes and not nsIWidgets? The latter would seem more
> logical...
> 

Not sure what you're asking here. The events are fired via widget->DispatchEvent.
DOM nodes are used as arguments to the methods so that they can be called from JS.

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Hmm. How about two interfaces then, an nsIWidget* one here and some extra (chrome only) methods on nsIDOMWindow*?

Comment 5

[Neil Deakin]

Adding a chrome-only window version would be ok too, although I don't think the nsIWidget version would be needed as well, as nsIWidget::DispatchEvent is already available.

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

OK then...

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Callum says he's had problems injecting synthetic key events due to focus. Is this a problem here, or does the right testing window always have focus anyway?

Comment 8

[Neil Deakin]

Problems with key events using this patch? The events will naturally be directed at whatever has focus in the window, so if nothing has focus the key event won't happen.

I'm thinking that the chrome-only nsIDOMWindowUtils would be a good place to put these methods.

Comment 9

[Neil Deakin]

One other thing is that the node argument will still be necessary, as nodes inside popups have a different widget.

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

With this approach, for key events to work, the application has to have focus. You can't run key tests and use another application at the same time.

Comment 11

[Neil Deakin]

Are you recommending a different approach for key event testing?

Whereabouts are the window focus checks for key events handled?

Comment 12

[Neil Deakin]

Attachment: put functions in windowutils

This is a simpler patch that adds two methods to nsIDOMWindowUtils

Comment 13

[Boris Zbarsky [:bzbarsky]]

So the reason we're dispatching to widgets, not elements, is that the events might need to hit anonymous content, etc?

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Targeting elements makes sense for some situations. For others, like say if you just want to fire events at a window and use/test Mozilla's focus and mouse event targeting code, then you probably want the widget.

Comment 15

[Neil Deakin]

Comment on attachment 250848 [details] [diff] [review]
put functions in windowutils

OK, this patch is probably ok for now. Still need to figure out how to fire key events in unfocused windows

Comment 16

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

Comment on attachment 250848 [details] [diff] [review]
put functions in windowutils

I guess the patch isn't updated to use new APIs from Bug 177805.

Comment 17

[Neil Deakin]

Yes, the two calls to NSTwipsToIntPixels should be calls to presContext->AppUnitsToDevPixels

Comment 18

[Johnny Stenback (:jst)]

Comment on attachment 250848 [details] [diff] [review]
put functions in windowutils

r=jst

Comment 19

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Why do we need the aNode parameters? Can't we just assume the root element in both methods if that matters?

It seems to me that we could and should make SendKeyEvent work even when the application window is not focused. That doesn't have to be done for this bug though.

Comment 20

[Neil Deakin]

(In reply to comment #19)
> Why do we need the aNode parameters? Can't we just assume the root element in
> both methods if that matters?

So that events can be fired at elements in xul popups.

Comment 21

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Why don't they already work, thanks to this code:
http://lxr.mozilla.org/seamonkey/source/layout/base/nsPresShell.cpp#5253
? That should handle mouse events. Key events should go to the focused element even if it's a XUL popup. Right? 

Comment 22

[Neil Deakin]

Attachment: This version doesn't use a node argument

Comment 23

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 256030 [details] [diff] [review]
This version doesn't use a node argument

good.

Sending key events does not work when the application window is not focused, right? If so, we should document that. And we should file a bug about fixing it --- and fix the bug :-).

Comment 24

[Neil Deakin]

Filed bug 371822 on the window focus issue.

Comment 25

[Jonathan Watt [:jwatt]]

Is there any reason why this doesn't support 'click', Neil?

Comment 26

[Neil Deakin]

A click is a combination of mousedown/mouseup. The click event is a higher level event that is generated as a result of this, that is, the widget layer doesn't send click events, they are created later on.

Comment 27

[Jonathan Watt [:jwatt]]

I see, so you have to send a mousedown followed by a mouseup if you want to trigger click listeners. Thanks.