Closed Bug 53640 Opened 24 years ago Closed 23 years ago

addEventListener() for event capture not always registering

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Platform:
x86
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9

People

(Reporter: dannyg, Assigned: joki)

References

Details

(Keywords: testcase)

Attachments

(5 files)

attached html testcase taken from inline testcase
1.86 KB, text/html
Details
A working example (I only took one line out!)
1.87 KB, text/html
Details
My little "Display event information" testcase
3.83 KB, text/html
Details
Patch for 49120 and 53640, part 1
57.78 KB, patch
Details | Diff | Splinter Review
Patch for 49120 and 53640, part 2
11.94 KB, patch
Details | Diff | Splinter Review 
The following example shows multiple event bugs, depending on the build you use.
In M17 the problems are:
 1. addEventListener("eventName",listenerFunc, true) doesn't register the
    capture listener when set after the page loads (the bubble version does,
    however).
 2. removeEventListener() doesn't.

In one of the nightly builds (90908), the code yields the following problems:
 1. addEventListener("eventName",listenerFunc, true) doesn't register the
    capture listener when set after the page loads (the bubble version does,
    however).
 2. The bubbled eventPhase reports 3 when it should be 1.


Here's the test case:

<HTML>
<HEAD>
<TITLE>W3C Event Model Lab</TITLE>
<SCRIPT LANGUAGE="JavaScript">
// add event listeners
function addBubbleListener() {
	document.getElementById("myP").addEventListener("click", reportEvent, false)
}
function addCaptureListener() {
	document.getElementById("myP").addEventListener("click", reportEvent, true)
}
// remove event listeners
function removeBubbleListener()  {
	document.getElementById("myP").removeEventListener("click", reportEvent, false)
}
function removeCaptureListener() {
	document.getElementById("myP").removeEventListener("click", reportEvent, true)
}
// display details about any click event targeted at mySPAN's text node
function reportEvent(evt) {
	if (evt.target.parentNode.id == "mySPAN") {
		var msg = "Event processed at " + evt.currentTarget.tagName +
			" element (event phase = " + evt.eventPhase + ").\n"
		document.controls.output.value += msg
	}
}
// clear the details textarea
function clearTextArea() {
	document.controls.output.value = ""
}
</SCRIPT>
</HEAD>
<BODY>
<H1>W3C Event Model Lab</H1>
<HR>
<P ID="myP"><SPAN ID="mySPAN">This paragraph (a SPAN element nested inside a P
element) can be set to listen for "click" events.</SPAN></P>
<HR>
<P STYLE="font-weight:bold">Control Panel</P>
<FORM NAME="controls">
<P>"Bubble"-type click listener: <INPUT TYPE="button" VALUE="Add to P"
onClick="addBubbleListener()">&nbsp;
<INPUT TYPE="button" VALUE="Remove from P" onClick="removeBubbleListener()"><BR>
"Capture"-type click listener: <INPUT TYPE="button" VALUE="Add to P"
onClick="addCaptureListener()">&nbsp;
<INPUT TYPE="button" VALUE="Remove from P" onClick="removeCaptureListener()"></P>
<P>Examine click event characteristics:&nbsp;<INPUT TYPE="button" VALUE="Clear"
onClick="clearTextArea()"><BR>
<TEXTAREA NAME="output" COLS="80" ROWS="6" WRAP="virtual"></TEXTAREA>
</FORM>
</BODY>
</HTML>
Updating QA Contact.
QA Contact: janc → lorca
Reporter are you still seeing this on the latest nightlies?
setting bug status to New
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 64742 has been marked as a duplicate of this bug. ***
There is a good testcase on bug 64742 you might want to check out when you get
around to testing this.
Keywords: testcase
OS: other → All
Link to testcase from duplicate bug:
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=22153

Assigning, setting milestone.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9
>2. The bubbled eventPhase reports 3 when it should be 1.
should that be 1?? not when I take a look at:

http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/events.html#Events-Event

-- begin snap --
 // PhaseType
  const unsigned short      CAPTURING_PHASE                = 1;
  const unsigned short      AT_TARGET                      = 2;
  const unsigned short      BUBBLING_PHASE                 = 3;
-- end snap --

You know what, the summary is incorrect. In this example the addEventListener()
is working and so does removeEventListener(). If you take a close look to that
testcase of my, you will see, and I only took one line out. In the testcase
there's a line like this:

"This paragraph (a SPAN element nested inside a P element) can be set to listen
for "click" events."(x)

You see I put that (x) in. That's exactly the place to put your mouse pointer on
and click, then it will display the text in that textarea. So the
addEventListener() is registered.

If I take this snap (same as testcase): 
<p id="myP">before<span>inside</span>after<p>

Then in this case the DOM sets that listener to the <p> element, as it should. 
But if you trigger an click event on that <span> element, you trigger an event
on #text and that doesn't get dispatched to the listener. So I belief that's the
main issue here, right?

The DOM needs to take a look at it's anchestors if there's an event listener
active, an dispatch events to that listener. BTW, should all posible
HTMLhtmlelement's be dispatched to that listener?

note 1: event.bubbles always returns true for capture events
note 2: event.eventPhase doesn't return 1 for capture events, but 3

Last testcase, the same with additional event information
I have some concerns about attachment 22153 [details] of that other bug. I just took a
quick look into the DOM 2 Event specs. I belief that this testcase does exactly
what it has to do. Let me explain, "mySpan3" is a bubble event, and it works.
Both "mySpan1" and "mySpan2" are capture events and should not work in this
testcase, as you can read in the specs:

<quote>
A capturing EventListener will not be triggered by events dispatched directly to
the EventTarget upon which it is registered.
</quote>

Both EventListeners are set directly _on_ those spans, and by clicking on that
_target_ and the event should not fire, per W3C specs! The fact that the capture
event on that specific <div> element works seems closely related to this:

<quote>
Event capture only allows interception of events which are targeted at
descendants of the capturing EventTarget
</quote>

That red line after the text, seems to be an descendant of the registered
EventListener. 

Please feel free to correct me if I'm wrong. I love to learn new things that I
might oversee on this issue. The misty part of this is that W3C specs don't talk
specific about nested elements, or I did'nt find that part of the specs.

Most friendly HJ.
Sorry this seems to be also very important for the testcases:

<quote>
It does not allow interception of events targeted to the capturer's ancestors,
its siblings, or its sibling's descendants.
</quote>
Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok

    
    

    
  


  

    
    

    
  
sr = jst

    
    

    
  
r = peterv

Fixed.

Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED

    
    

    
  
*** Bug 67535 has been marked as a duplicate of this bug. ***

    
    

    
  
QA contact updated
QA Contact: gerardok → madhur

    
    

    
  
verified on build 2000-08-07 and 2001-07-09
Status: RESOLVED → VERIFIED
Component: Event Handling → User events and focus handling

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: