All users were logged out of Bugzilla on October 13th, 2018
For testing, there needs to be a way of sending low-level events at the widget level.
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...
(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*?
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?
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
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.
Are you recommending a different approach for key event testing? Whereabouts are the window focus checks for key events handled?
Created attachment 250848 [details] [diff] [review] put functions in windowutils This is a simpler patch that adds two methods to nsIDOMWindowUtils
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.
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 on attachment 250848 [details] [diff] [review] put functions in windowutils I guess the patch isn't updated to use new APIs from Bug 177805.
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.
(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?
Created attachment 256030 [details] [diff] [review] This version doesn't use a node argument
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 :-).
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?
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.