Last Comment Bug 60212 - RFE: DOM 2 UIEvent interface
: RFE: DOM 2 UIEvent interface
Status: RESOLVED FIXED
: dom2
Product: Core
Classification: Components
Component: DOM: Events (show other bugs)
: Trunk
: All All
: P3 normal with 8 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 103110 128778 194648 (view as bug list)
Depends on:
Blocks: 242494 277890
  Show dependency treegraph
 
Reported: 2000-11-15 12:13 PST by jsp
Modified: 2014-04-26 03:08 PDT (History)
30 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
implement DOMActivate and infrastructure for UIEvents (48.11 KB, patch)
2004-04-27 18:15 PDT, Brian Ryner (not reading)
jst: review+
jst: superreview+
mozilla: approval1.7.5-
Details | Diff | Review
diff -w of the above (46.93 KB, patch)
2004-04-27 18:15 PDT, Brian Ryner (not reading)
no flags Details | Diff | Review
testcase (4.08 KB, text/html)
2004-04-27 18:17 PDT, Brian Ryner (not reading)
no flags Details

Description jsp 2000-11-15 12:13:18 PST
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, jst@mozilla.com) 2000-11-18 18:22:40 PST
Reassigning to the DOM event system owner.
Comment 2 Keyser Sose 2000-12-18 17:33:14 PST
Marking NEW so someone will look at it.
Comment 3 joki (gone) 2001-01-22 13:23:46 PST
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 2001-05-29 15:49:29 PDT
QA Contact Update
Comment 5 basic 2002-01-11 13:18:50 PST
hmm this would be really useful in xbl...
Comment 6 Vladimir Ermakov 2002-04-03 14:50:47 PST
*** Bug 128778 has been marked as a duplicate of this bug. ***
Comment 7 Vladimir Ermakov 2002-05-22 14:52:41 PDT
*** Bug 103110 has been marked as a duplicate of this bug. ***
Comment 8 Josh Birnbaum 2003-02-23 17:23:14 PST
*** Bug 194648 has been marked as a duplicate of this bug. ***
Comment 9 leonard 2003-02-23 17:48:35 PST
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 2003-07-03 22:03:04 PDT
any plans to implement this?
Comment 11 Brian Ryner (not reading) 2004-04-27 18:05:05 PDT
-> me
Comment 12 Brian Ryner (not reading) 2004-04-27 18:15:23 PDT
Created attachment 147199 [details] [diff] [review]
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) 2004-04-27 18:15:55 PDT
Created attachment 147200 [details] [diff] [review]
diff -w of the above
Comment 14 Brian Ryner (not reading) 2004-04-27 18:17:36 PDT
Created attachment 147201 [details]
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, jst@mozilla.com) 2004-04-29 21:32:21 PDT
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) 2004-04-30 11:18:03 PDT
Comment on attachment 147199 [details] [diff] [review]
implement DOMActivate and infrastructure for UIEvents

oops i meant to request r+sr
Comment 17 Aaron Leventhal 2004-04-30 20:30:14 PDT
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 2004-05-05 13:31:35 PDT
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 2004-05-06 13:42:56 PDT
...and bug 242494 and bug 242439. Hello... this checkin broke a lot of forms.
Comment 20 Rob Borek 2004-05-07 14:12:08 PDT
Please back out this patch until it's ready and has been tested against the
various bugs in the dependency graph.
Comment 21 Alereon 2004-05-11 07:10:09 PDT
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 2004-05-14 09:54:02 PDT
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] 2004-08-10 11:12:48 PDT
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) 2005-08-04 03:41:22 PDT
We are supporting DOMActivate now. This patch has not been backed out.
Comment 25 jsp 2005-08-04 06:31:57 PDT
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 Cater 2005-10-30 10:32:25 PST
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.

Note You need to log in before you can comment on or make changes to this bug.