All users were logged out of Bugzilla on October 13th, 2018

Need a way to synthesize events for automated testing

RESOLVED FIXED

Status

()

RESOLVED FIXED
12 years ago
9 years ago

People

(Reporter: enndeakin, Assigned: enndeakin)

Tracking

(Blocks: 1 bug)

Trunk
x86
Mac OS X
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Assignee)

Description

12 years ago
For testing, there needs to be a way of sending low-level events at the widget level.
(Assignee)

Comment 1

12 years ago
Created attachment 249274 [details] [diff] [review]
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.
Why are you targeting DOM nodes and not nsIWidgets? The latter would seem more logical...
(Assignee)

Comment 3

12 years ago
(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.
Hmm. How about two interfaces then, an nsIWidget* one here and some extra (chrome only) methods on nsIDOMWindow*?
(Assignee)

Comment 5

12 years ago
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.
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?
(Assignee)

Comment 8

12 years ago
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.
Status: NEW → ASSIGNED
(Assignee)

Comment 9

12 years ago
One other thing is that the node argument will still be necessary, as nodes inside popups have a different widget.
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.
(Assignee)

Comment 11

12 years ago
Are you recommending a different approach for key event testing?

Whereabouts are the window focus checks for key events handled?
(Assignee)

Comment 12

12 years ago
Created attachment 250848 [details] [diff] [review]
put functions in windowutils

This is a simpler patch that adds two methods to nsIDOMWindowUtils
(Assignee)

Updated

12 years ago
Blocks: 368097
So the reason we're dispatching to widgets, not elements, is that the events might need to hit anonymous content, etc?
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.
(Assignee)

Comment 15

12 years ago
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
Attachment #250848 - Flags: superreview?(roc)
Attachment #250848 - Flags: review?(jst)

Comment 16

12 years ago
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.
(Assignee)

Comment 17

12 years ago
Yes, the two calls to NSTwipsToIntPixels should be calls to presContext->AppUnitsToDevPixels
Comment on attachment 250848 [details] [diff] [review]
put functions in windowutils

r=jst
Attachment #250848 - Flags: review?(jst) → review+
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.
(Assignee)

Comment 20

12 years ago
(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.
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? 

Updated

12 years ago
Blocks: 370958
(Assignee)

Comment 22

12 years ago
Created attachment 256030 [details] [diff] [review]
This version doesn't use a node argument
Attachment #249274 - Attachment is obsolete: true
Attachment #250848 - Attachment is obsolete: true
Attachment #256030 - Flags: superreview?(roc)
Attachment #256030 - Flags: review?(roc)
Attachment #250848 - Flags: superreview?(roc)
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 :-).
Attachment #256030 - Flags: superreview?(roc)
Attachment #256030 - Flags: superreview+
Attachment #256030 - Flags: review?(roc)
Attachment #256030 - Flags: review+
(Assignee)

Comment 24

12 years ago
Filed bug 371822 on the window focus issue.
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Is there any reason why this doesn't support 'click', Neil?
(Assignee)

Comment 26

9 years ago
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.
I see, so you have to send a mousedown followed by a mouseup if you want to trigger click listeners. Thanks.
You need to log in before you can comment on or make changes to this bug.