242763 - eventPhase property of event object was "2"(Target Phase) even though Bubble Phase when object is the target object of event

Status: UNCONFIRMED

(Core :: DOM: Events, defect, P5)

Description

[WADA:World Anti-bad-Duping Agency]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040505
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040505

Spin off from Bug 242091 Comment 2 since this issue has no relation to the bug.

I tested both addEventListener(...,true) and addEventListener(...,false) for Bug
242091 and DOM-2 events were successufully fired in both target phase and bubble
phase(2004042808-trunk/Win-2K).
However, when second event listening(probably bubble phase) of target element of
the event, eventPhase property of event object was "2"(target phase) instead of
"3"(bubble phase).
I think this should be "3" (Bubble Phase).


Reproducible: Always
Steps to Reproduce:




(Test case for Event-Object.eventPhase display)

[Case-1] in Attachment 147346 [details] in Bug 242091

<div-1 onClick-1> <div-2 onClick-2> <div-3 onClick-3> ... </div> </div> </div>
Alert for Event-object's properties is issued when event listening.
Alert is issued by onClick script.

When I clicked <div-3>, inner most div, events were scheduled in next sequence.
(1) Target phase of <div-1>
  (2) Target phase of <div-2>
    (3) onClick of <div-3>
    (4) Target phase by addEventListener(...,true) for <div-3>(=target object)
    (5) Bubble phase? by addEventListener(...,false) for <div-3>(=target object)
  (6) onClick of <div-2>
  (7) Bubble phase of <div-2>
(8) onClick of <div-1>
(9) Bubble phase of <div-1>

At step (1) & (2) & step(4), Event-Object.eventPhase was "2"(Target phase) as
expected.
At step (5) Event-Object.eventPhase was "2"(Target phase) instead of "3"(Bubble
phase).
At step(7) & (9), Event-Object.eventPhase was "3"(Bubble phase) as expected.

I think Event-Object.eventPhase at step(5) should be "3" (Bubble Phase).

Comment 1

[WADA:World Anti-bad-Duping Agency]

Sorry. Link to test case was lost.
http://bugzilla.mozilla.org/attachment.cgi?id=147346&action=view

Comment 2

[Boris Zbarsky [:bzbarsky]]

Probably a dup of the "capturing listeners should not fire at target" bug...

Comment 3

[WADA:World Anti-bad-Duping Agency]

Bug 235441 ?
If trigering eventListner of event target element is improper, this bug can be
closed as dupe of Bug 235441.
But  trigering eventListner of event target element is proper, this bug is
different from Bug 235441.

I do not know word of "Target Phase" or "Bubble Phase" includes target element
itself or not.
I do not know trigering eventListner of event target is proper or improper.

(Result of additional test)
If addEventLisner(...,true) only for <div-3>, eventLisning was fired only once.
If addEventLisner(...,false) only for <div-3>, eventLisning was fired only once.
So (4) is "target Phase" and (5) is "Bubble Phase".
EventLisner trigering is done as expected(if trigering for target is proper). 

Comment 4

[Aurélien Maille]

The sequence should be:

(1) capturing phase (but it is target phase, see fixed bug 245569) of <div-1>
(2) same of previous but on <div-2>
(3) nothing. But capturing click event registered on <div-3> is fired, it should
not be. (See bug 235441)
(4) target phase on <div-3>
(5) Bubble phase of <div-2>
(6) Bubble phase of <div-1>

target phase instead of bubble phase on <div-3> is not a bug.

But i have found another bug on event phase.
See the next testcase. On the first click on #span1 (at this time, #span1
doesn't have EventListener registered on itself), eventPhase should be AT_TARGET.
eventPhase can be BUBBLING_PHASE only if the EventListener has been triggered by
an event of same type on a descendant of EventTarget.

Comment 5

[Aurélien Maille]

Attachment: testcase for comment #4

Comment 6

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 7

[WADA:World Anti-bad-Duping Agency]

This bug is still not resolved, because "what should be" is still unclear.

Comment 8

[Alex Vincent [:WeirdAl]]

(In reply to comment #2)
> Probably a dup of the "capturing listeners should not fire at target" bug...

Bug 235441?

Comment 9

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #8)
> (In reply to comment #2)
> > Probably a dup of the "capturing listeners should not fire at target" bug...
> 
> Bug 235441?

I think so, and it is also mentioned by comment #4.
I think comment #2 and comment #4 is correct now, although I still have question
in comment #3.
I'd like to close this bug as INVALID(can be DUP of Bug 235441).
But problem mentioned by Bobe in comment #4 apprently exists(I can re-create it.)...
What should I do?

Comment 10

[Aurélien Maille]

(In reply to comment #9)
> But problem mentioned by Bobe in comment #4 apprently exists(I can re-create
it.)...
> What should I do?
> 

I was wrong. 
Target Phase occurs only when the event is dispatched to the target node (as
defined in DOM3). In my example, #span1 isn't the target node (if no 'click'
listener is registered on himself) so eventPhase value at BUBBLING_PHASE is correct.

http://www.w3.org/TR/2003/NOTE-DOM-Level-3-Events-20031107/events.html#Events-flow

Comment 11

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #10)
Thanks. I can close this bug now.

*** This bug has been marked as a duplicate of 235441 ***

Comment 12

[WADA:World Anti-bad-Duping Agency]

Decision of whether WONTFIX Bug 235441 or not seems to have been postponed to future. So, re-open this bug with setting dependency, because kick of eventListener at event target will continue.

I think following order/value is reasonable, if eventListener's are kicked for event target object.
  1. eventListner(true) with "Target Phase"
  2. event handler of the event target object
  3. eventListener(false) with "Bubble Phase"

Comment 13

[Olli Pettay [:smaug][[e-mail]]]

What does "event handler of the event target object" mean?

Comment 14

[Olli Pettay [:smaug][[e-mail]]]

And the testcase doesn't seem valid:
"# currentTarget: div2, target: span1, phase: BUBBLING_PHASE - eventPhase should be AT_TARGET"
The comment "eventPhase should be AT_TARGET" isn't right.

Comment 15

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #13)
> What does "event handler of the event target object" mean?

onClick handler by <div onClick="..."> for click event of the div. 

(In reply to comment #14)
> And the testcase doesn't seem valid:

Do you refer which test case?
Test cases in my Comment #0? (Sorry but attached to other bug)
Or test case of Comment #4 / Comment #5 ?
If latter, read Comment #10, please. 

Comment 16

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.