Closed
Bug 60212
Opened 24 years ago
Closed 11 years ago
RFE: DOM 2 UIEvent interface
Categories
(Core :: DOM: Events, defect, P3)
Core
DOM: Events
Tracking
()
RESOLVED
FIXED
People
(Reporter: jsp, Unassigned)
References
Details
(Keywords: dom2)
Attachments
(3 files)
48.11 KB,
patch
|
jst
:
review+
jst
:
superreview+
mkaply
:
approval1.7.5-
|
Details | Diff | Splinter Review |
46.93 KB,
patch
|
Details | Diff | Splinter Review | |
4.08 KB,
text/html
|
Details |
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 2•24 years ago
|
||
Marking NEW so someone will look at it.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 3•24 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
Updated•24 years ago
|
Component: DOM Level 2 → DOM Events
Comment 6•22 years ago
|
||
*** Bug 128778 has been marked as a duplicate of this bug. ***
Comment 7•22 years ago
|
||
*** Bug 103110 has been marked as a duplicate of this bug. ***
Comment 8•22 years ago
|
||
*** 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?
Comment 11•20 years ago
|
||
-> me
Assignee: joki → bryner
Status: ASSIGNED → NEW
Target Milestone: Future → mozilla1.8alpha
Comment 12•20 years ago
|
||
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•20 years ago
|
||
Comment 14•20 years ago
|
||
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.
Updated•20 years ago
|
Attachment #147199 -
Flags: review?(jst)
Comment 15•20 years ago
|
||
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 16•20 years ago
|
||
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•20 years ago
|
Attachment #147199 -
Flags: superreview?(jst) → superreview+
Comment 17•20 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•20 years ago
|
||
The patch checked in Apr 30 caused bug 242709 (its summary sounds like "duh" but actually I think it's a problem).
Comment 19•20 years ago
|
||
...and bug 242494 and bug 242439. Hello... this checkin broke a lot of forms.
Comment 20•20 years ago
|
||
Please back out this patch until it's ready and has been tested against the various bugs in the dependency graph.
Comment 21•20 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•20 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.
Attachment #147199 -
Flags: approval1.7.3?
Comment 23•20 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-
Comment 24•19 years ago
|
||
We are supporting DOMActivate now. This patch has not been backed out.
QA Contact: vladimire → ian
Reporter | ||
Comment 25•19 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•19 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.
Updated•18 years ago
|
Assignee: bryner → events
Target Milestone: mozilla1.8alpha1 → ---
Updated•15 years ago
|
Assignee: events → nobody
QA Contact: ian → events
Updated•11 years ago
|
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•