309273 - (hasEventListenerNS) Implement nsIDOM3EventTarget::hasEventListenerNS()

Status: RESOLVED WONTFIX

(Core :: DOM: Events, defect)

Description

[Jan Varga [:janv]]

We need this for one of our customers.

Comment 1

[Jan Varga [:janv]]

Attachment: patch

Comment 2

[Jan Varga [:janv]]

Attachment: patch2

Comment 3

[Alex Vincent [:WeirdAl]]

I don't see this particular method in the W3C Note on DOM 3 Events... can you
explain for me what this does?

Comment 4

[Anne (:annevk)]

It was in an older draft:
<http://www.w3.org/TR/2002/WD-DOM-Level-3-Events-20020208/events.html#Events3-isRegisteredHere>.
No longer in the current version I believe. I can not find the reason for it
being removed.

Comment 5

[Peter Van der Beken [:peterv]]

Comment on attachment 196765 [details] [diff] [review]
patch2

>Index: dom/src/base/nsDOMClassInfo.cpp
>===================================================================

Don't you need to add DOM_CLASSINFO_MAP_ENTRY(nsIDOM3EventTarget) to Window,
Text, Comment, CDataSection, ProcessingInstruction,
XMLStylesheetProcessingInstruction, ChromeWindow,
DOM_CLASSINFO_SVG_GRAPHIC_ELEMENT_MAP_ENTRIES, SVGSVGElement and
SVGSymbolElement?

>Index: content/base/src/nsDocument.cpp
>===================================================================

>+nsDocument::IsRegisteredHere(const nsAString& aType, PRBool* _retval)

Please make _retval aResult.

>Index: content/base/src/nsGenericElement.cpp
>===================================================================

>+nsDOMEventRTTearoff::IsRegisteredHere(const nsAString& aType, PRBool* _retval)

Please make _retval aResult.

>Index: content/events/src/nsEventListenerManager.cpp
>===================================================================

>+nsEventListenerManager::IsRegisteredHere(const nsAString& aType, PRBool* _retval)

Please make _retval aResult.

>+    *_retval = (GetListenersByType(eEventArrayType_Hash, &key, PR_FALSE)) != nsnull;

No need for the second set of parentheses.

Comment 6

[Jan Varga [:janv]]

Thanks Peter, I'll fix it as you suggested.

Comment 7

[Jan Varga [:janv]]

(In reply to comment #4)
> It was in an older draft:
>
<http://www.w3.org/TR/2002/WD-DOM-Level-3-Events-20020208/events.html#Events3-isRegisteredHere>.
> No longer in the current version I believe. I can not find the reason for it
> being removed.

Yeah, it seems they removed it in the current draft. Anyway, this method can be
very useful for some apps (e.g. document inspection, you can't just check for
"on" + eventName, some event listeners can be registered dynamically) and I
wanted to contribute it back to main mozilla tree.

Comment 8

[Hixie (not reading bugmail)]

Woah woah woah. This method _does_ exist in DOM3 Events, it has just been
renamed and had its semantics improved:

   http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events3-hasEventListenerNS
   http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events3-willTriggerNS

I'd strongly like to encourage that we don't take this patch as is; we should
instead support the standard methods here.

Comment 9

[Jan Varga [:janv]]

Ian, is this just about ranaming isRegisteredHere to hasEventListenerNS?

Comment 10

[Peter Van der Beken [:peterv]]

Ah, right, please rename it. The semantics didn't change as far as I can see.

Comment 11

[Hixie (not reading bugmail)]

It takes a different number of arguments. For now since we don't support
namespaces on addEventListener you can just ignore the namespace argument (all
event handlers will have namespace null, and so all of them should match
regardless of the namespace, as I understand it).

However, I would strongly recommend reading the spec, and making sure that what
you are implementing matches the spec.

Comment 12

[Jan Varga [:janv]]

addGroupedEventListener -> addEventListenerNS
removeGroupedEventListener -> removeEventListenerNS
canTrigger ->  willTriggerNS
isRegisteredHere ->  hasEventListenerNS

All new DOM3 methods now have |namespaceURI| as the first argument

Methods addGroupedEventListener and removeGroupedEventListener are currently
implemented in mozilla. canTrigger and isRegisteredHere are not.

The semantics didn't change for isRegisteredHere/hasEventListenerNS
See 
http://www.w3.org/TR/2002/WD-DOM-Level-3-Events-20020208/events.html#Events3-isRegisteredHere
http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events3-hasEventListenerNS

The semantics did change for addGroupedEventListener/addEventListenerNS and 
removeGroupedEventListener/removeEventListenerNS
See
http://www.w3.org/TR/2002/WD-DOM-Level-3-Events-20020208/events.html#Events3-addGroupedEventListener
http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events3-addEventListenerNS

So it should be safe to rename canTrigger and isRegisteredHere and add
implementation for isRegisteredHere based on my original patch.

Comment 13

[Jan Varga [:janv]]

Btw, there was a bug about nsIDOM3EventTarget.idl being distributed in the SDK.
Someone wanted to freeze this interface IIRC.

Comment 14

[alexander :surkov (:asurkov)]

(In reply to comment #8)
> Woah woah woah. This method _does_ exist in DOM3 Events, it has just been
> renamed and had its semantics improved:
> 
>    http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events3-hasEventListenerNS
>    http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events3-willTriggerNS

I can't find these methods in dom level3 events. Do they still exist?

Comment 15

[Alex Vincent [:WeirdAl]]

per comment 12.

Comment 16

[alexander :surkov (:asurkov)]

Alex, http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events3-hasEventListenerNS link is broken

Comment 17

[Alex Vincent [:WeirdAl]]

oops, yeah, I don't see it either.  WONTFIX?

Comment 18

[alexander :surkov (:asurkov)]

(In reply to comment #17)
> oops, yeah, I don't see it either.  WONTFIX?
> 

I'd like to see this feature. It should help to fix bug 301621.

Comment 19

[alexander :surkov (:asurkov)]

I wonder what is a reason due to they has been removed?