60212 - RFE: DOM 2 UIEvent interface

Status: RESOLVED FIXED

(Core :: DOM: Events, defect, P3)

Description

[jsp]

I tried to make use of the DOMActivate event, to no avail. I then performed a
case-insensitive search for "domactivate" in the M18 source code and found no
matches. I assume this means that the UIEvent interface is not yet implemented.
If it's not on anyone's radar screen, I'd like to see it get there eventually.

My hope is that it'll be useful for barring activation of data entry elements,
since (unlike the HTML focus event) the DOMActivate event is cancelable. It's
not entirely clear to me from the DOM spec what cancelling activation might
mean, so it's possible that I'm off base here, but I assume the authors saw
*some* use for these events, or they wouldn't have put 'em in the spec.

Comment 1

[Johnny Stenback (:jst)]

Reassigning to the DOM event system owner.

Comment 2

[Keyser Sose]

Marking NEW so someone will look at it.

Comment 3

[joki (gone)]

We currently don't plan to implement the UIEvents for the next release of 
mozilla.


This bug has been marked "future" because the original netscape engineer
working on this is over-burdened. If you feel this is an error, that you or
another known resource will be working on this bug,or if it blocks your work
in some way -- please attach your concern to the bug for reconsideration.

Comment 4

[Vladimir Ermakov]

QA Contact Update

Comment 5

[basic]

hmm this would be really useful in xbl...

Comment 6

[Vladimir Ermakov]

*** Bug 128778 has been marked as a duplicate of this bug. ***

Comment 7

[Vladimir Ermakov]

*** Bug 103110 has been marked as a duplicate of this bug. ***

Comment 8

[Josh Birnbaum]

*** Bug 194648 has been marked as a duplicate of this bug. ***

Comment 9

[leonard]

Just thought I'd leave a note: I'm working on a DHTML ComboBox using standard
form elements (input type=text, select) which requires DOMActivate (or some way)
to expand the select form element.  Are there alternatives to using UIEvents?

Comment 10

[basic]

any plans to implement this?

Comment 11

[Brian Ryner (not reading)]

-> me

Comment 12

[Brian Ryner (not reading)]

Attachment: implement DOMActivate and infrastructure for UIEvents

This patch implements DOMActivate for HTML input, button, and anchor elements,
and adds the infrastructure to support DOMFocusIn and DOMFocusOut (those events
are not dispatched currently, but that's next).

Summary of changes:
- Add UI events to lists of events where needed (this is pretty
self-explanatory)
- Implement nsDOMEvent::InitUIEvent.  Refactor Init*Event implementations to
share common code.
- For anchor, input, and button elements, make the default action of a left
click be to dispatch DOMActivate.  Whatever behavior is currently the default
action of left click is now the default action of DOMActivate.	This required
some special handling for input elements, which I explained in the comments.
- Added nsIDOMUIListener C++ interface for receiving UI Events.
- Cleaned up some unneeded or incorrect references to nsIDOMUIEvent.
- Exposed DOMActivate, DOMFocusIn, DOMFocusOut to gtk embedding widget. and
stubs in Photon embedding widget.

The scariest changes here are the changes to
nsHTMLInputElement::HandleDOMEvent().  It passes everything in my test case and
I couldn't find anything else that breaks, but this code needs some careful
scrutiny.

It's also worth noting that this works automatically for activation via
keyboard because we're already hacking that to dispatch a click event.

I based my understanding of how DOMActivate should work on the DOM 2 events
spec and the DOM 3 events working group note.

Comment 13

[Brian Ryner (not reading)]

Attachment: diff -w of the above

Comment 14

[Brian Ryner (not reading)]

Attachment: testcase

This is a testcase I'd written to test DOMActivate functionality.  All controls
should put up an alert when activated; for controls marked as cancel, the
default action (checking the box, submitting the form, etc) should not occur.

Comment 15

[Johnny Stenback (:jst)]

Comment on attachment 147199 [details] [diff] [review]
implement DOMActivate and infrastructure for UIEvents

- In EmbedEventListener::Activate():

+  gtk_signal_emit(GTK_OBJECT(mOwner->mOwningWidget),
+		  moz_embed_signals[DOM_ACTIVATE],
+		  (void *)uiEvent, &return_val);

Tabs!

- In EmbedEventListener::FocusIn()

+  gtk_signal_emit(GTK_OBJECT(mOwner->mOwningWidget),
+		  moz_embed_signals[DOM_FOCUS_IN],
+		  (void *)uiEvent, &return_val);

More tabs!

- In EmbedEventListener::FocusOut():

+  gtk_signal_emit(GTK_OBJECT(mOwner->mOwningWidget),
+		  moz_embed_signals[DOM_FOCUS_OUT],
+		  (void *)uiEvent, &return_val);

And yet more :)

- In EmbedPrivate::AttachListeners():

+  rv = mEventReceiver->AddEventListenerByIID(eventListener,
+					     NS_GET_IID(nsIDOMUIListener));

And more... same in gtkmozembed2.cpp and EmbedEventListener.h

r=jst

Comment 16

[Brian Ryner (not reading)]

Comment on attachment 147199 [details] [diff] [review]
implement DOMActivate and infrastructure for UIEvents

oops i meant to request r+sr

Comment 17

[Aaron Leventhal]

Q's:

1) Does it fire DOMActivate for keyboard events, like Enter? I believe it should.

2) Also will it work on generic elements? For example, will it work on:
.menuitem { -moz-user-focus: normal; }
<div class="menuitem" ondomactivate="blah();">My dhtml menuitem</div>
That should also work, right?

Comment 18

[Dan M]

The patch checked in Apr 30 caused bug 242709 (its summary sounds like "duh" but
actually I think it's a problem).

Comment 19

[Dan M]

...and bug 242494 and bug 242439. Hello... this checkin broke a lot of forms.

Comment 20

[Rob Borek]

Please back out this patch until it's ready and has been tested against the
various bugs in the dependency graph.

Comment 21

[Alereon]

Sorry to cause bugspam, but what's up with this checkin? It's been almost two
weeks since  we found out that this caused some heavy breakage, yet it hasn't
been backed out or changed. 

Comment 22

[Ilya Konstantinov]

I already integrated the part of this patch which resides in content/event/ into
my bug 238773 work. I hope the DOM-Events-related part of this patch will remain
intact, while the breakage reported in the recent bugs would be fixed.

Comment 23

[Mike Kaply [:mkaply]]

Comment on attachment 147199 [details] [diff] [review]
implement DOMActivate and infrastructure for UIEvents

Based on the comments in the bug, certainly not yet.

Comment 24

[Anne (:annevk)]

We are supporting DOMActivate now. This patch has not been backed out.

Comment 25

[jsp]

The bug appears mostly fixed in Deer Park alpha 2.  Firefox 1.0.x exhibits the
old behavior with the testcase.

I say "mostly fixed" because no alert box is displayed if either of the text
inputs in the testcase is clicked.  Instead, the following message appears in
the JavaScript console:

Error: [Exception... "'Permission denied to get property
XULElement.selectedIndex' when calling method:
[nsIAutoCompletePopup::selectedIndex]"  nsresult: "0x8057001e
(NS_ERROR_XPC_JS_THREW_STRING)"  location: "JS frame ::
https://bugzilla.mozilla.org/attachment.cgi?id=147201 :: handleClick :: line 20"
 data: no]
Source File: https://bugzilla.mozilla.org/attachment.cgi?id=147201
Line: 20

This message does not appear when any of the other controls are activated.

Furthermore, tabbing into a text input does not cause the alert box to display,
nor does it throw an error.  I would expect that tabbing into a text box would
activate it and therefore call the activate handler.  (I haven't looked at the
spec for a while, though, so my expectation may be naive.)

Comment 26

[Daniel C]

I get 

Error: [Exception... "'Permission denied to set property XULElement.selectedIndex' when calling method: [nsIAutoCompletePopup::selectedIndex]"  nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)"  location: "JS frame :: https://bugzilla.mozilla.org./attachment.cgi?id=147201 :: handleClick :: line 20"  data: no]
Source File: https://bugzilla.mozilla.org./attachment.cgi?id=147201
Line: 20

when clicking either textbox too.

It is possible to get the ondomactivate alert by fousing the textbox (onclick alert only) then pressing enter (onlick alert plus ondomactivate alert).

"radio with addEventListener/cancel" doesn't preventDefault (cancel) for me, but stays selected.