RFE: DOM 2 UIEvent interface

RESOLVED FIXED

Status

()

Core
DOM: Events
P3
normal
RESOLVED FIXED
17 years ago
3 years ago

People

(Reporter: jsp, Unassigned)

Tracking

({dom2})

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

17 years ago
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

Comment 2

17 years ago
Marking NEW so someone will look at it.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 3

17 years ago
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.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Keywords: dom2
Component: DOM Level 2 → DOM Events

Comment 4

16 years ago
QA Contact Update
QA Contact: vidur → vladimire

Comment 5

16 years ago
hmm this would be really useful in xbl...

Comment 6

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

Comment 7

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

Comment 8

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

Comment 9

15 years ago
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

14 years ago
any plans to implement this?
OS: Windows 2000 → All
Hardware: PC → All
-> me
Assignee: joki → bryner
Status: ASSIGNED → NEW
Target Milestone: Future → mozilla1.8alpha
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.
Created attachment 147200 [details] [diff] [review]
diff -w of the above
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.
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);

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
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)

Updated

13 years ago
Attachment #147199 - Flags: superreview?(jst) → superreview+

Comment 17

13 years ago
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

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

Comment 19

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

Comment 20

13 years ago
Please back out this patch until it's ready and has been tested against the
various bugs in the dependency graph.
Blocks: 243260

Comment 21

13 years ago
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

13 years ago
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.
No longer blocks: 243260

Updated

13 years ago
Attachment #147199 - Flags: approval1.7.3?

Comment 23

13 years ago
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-

Updated

13 years ago
Blocks: 277890

Comment 24

12 years ago
We are supporting DOMActivate now. This patch has not been backed out.
QA Contact: vladimire → ian
(Reporter)

Comment 25

12 years ago
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

12 years ago
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.
Assignee: bryner → events
Target Milestone: mozilla1.8alpha1 → ---
Assignee: events → nobody
QA Contact: ian → events

Updated

5 years ago
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.