Closed Bug 60212 Opened 21 years ago Closed 9 years ago

RFE: DOM 2 UIEvent interface


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






(Reporter: jsp, Unassigned)



(Keywords: dom2)


(3 files)

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.
Reassigning to the DOM event system owner.
Assignee: jst → joki
Marking NEW so someone will look at it.
Ever confirmed: true
We currently don't plan to implement the UIEvents for the next release of 

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.
Target Milestone: --- → Future
Keywords: dom2
Component: DOM Level 2 → DOM Events
QA Contact Update
QA Contact: vidur → vladimire
hmm this would be really useful in xbl...
*** Bug 128778 has been marked as a duplicate of this bug. ***
*** Bug 103110 has been marked as a duplicate of this bug. ***
*** Bug 194648 has been marked as a duplicate of this bug. ***
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?
any plans to implement this?
OS: Windows 2000 → All
Hardware: PC → All
-> me
Assignee: joki → bryner
Target Milestone: Future → mozilla1.8alpha
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
- 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

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.
Attached file 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.
Attachment #147199 - Flags: review?(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);


- 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

Attachment #147199 - Flags: review?(jst) → review+
Comment on attachment 147199 [details] [diff] [review]
implement DOMActivate and infrastructure for UIEvents

oops i meant to request r+sr
Attachment #147199 - Flags: superreview?(jst)
Attachment #147199 - Flags: superreview?(jst) → superreview+

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?
The patch checked in Apr 30 caused bug 242709 (its summary sounds like "duh" but
actually I think it's a problem).
Blocks: 242494
...and bug 242494 and bug 242439. Hello... this checkin broke a lot of forms.
Please back out this patch until it's ready and has been tested against the
various bugs in the dependency graph.
Blocks: 243260
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. 
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.
Attachment #147199 - Flags: approval1.7.3?
Comment on attachment 147199 [details] [diff] [review]
implement DOMActivate and infrastructure for UIEvents

Based on the comments in the bug, certainly not yet.
Attachment #147199 - Flags: approval1.7.3? → approval1.7.3-
Blocks: 277890
We are supporting DOMActivate now. This patch has not been backed out.
QA Contact: vladimire → ian
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 :: :: handleClick :: line 20"
 data: no]
Source File:
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.)
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 :: :: handleClick :: line 20"  data: no]
Source File:
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.
Assignee: bryner → events
Target Milestone: mozilla1.8alpha1 → ---
Assignee: events → nobody
QA Contact: ian → events
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.