Closed Bug 245569 Opened 20 years ago Closed 20 years ago

event.eventPhase always AT_TARGET even during capture/bubble

Categories

(Core :: DOM: Events, defect)

Product:
Core
Component:
DOM: Events
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: aaronr, Unassigned)

References

Details

Attachments

(2 files)

testcase for recreation
1.03 KB, text/html
Details
proposed fix v1
1.10 KB, patch
bryner
: review+
bryner
: superreview+
Details | Diff | Splinter Review 
I created a testcase that will add capture and bubbling event listeners on the
<html> tag in an xhtml document.  Both event listeners are for the "click" event
and both will use the same handler.  The handler prints out the
event.eventPhase, event.target and event.currentTarget.  The testcase also has
an <input type="button"/> which will be the target of the click even.  I noticed
that the event.eventPhase is always wrong.  It is always returned as AT_TARGET
even though the target is the pushbutton and the handler is on the <html>
element.  Shouldn't event.eventPhase be CAPTURING_PHASE the first time the
handler fires and BUBBLING_PHASE the second time that it fires?

I debugged this down to nsDOMEvent::GetEventPhase.  It only tests for one flag
at a time.  If that flag is set, it returns that value.  However, if two
different flags are set (i.e. NS_EVENT_FLAG_INIT|NS_EVENT_FLAG_CAPTURE), then
only the first value tested for is returned.  In our cases, NS_EVENT_FLAG_INIT
is always set, and paired with NS_EVENT_FLAG_CAPTURE during capture phase and
NS_EVENT_FLAG_BUBBLE when it is in bubble phase.  Since NS_EVENT_FLAG_INIT is
always set, AT_TARGET is always returned.

This was recreated on trunk built on 05/18 on Windows.  Probably is cross
platform, though.
Here is a testcase that shows the bug.
Depends on: 234455
Whoops. This makes XBL's phase="target" pretty useless...
Actually, while testing my fix, I've found that it seems like "phase" at all on
XBL handlers is pretty useless.  The XBL Handlers only seem to fire during
bubble phase.  If I put a handler via XBL on a button and the form element that
it is contained in, the button handlers get hit first then the form, even
capture handlers.  Seems to be related to bug 55288.
Weird... for my test case of nested phase="target" handlers, if there was no
phase="target" handler on the target then the parent phase="target" fired...
Attached patch proposed fix v1 — — Splinter Review 
This patch addresses the problem that I wrote the bug for, but you'll notice
inconsistencies between the returned event.eventPhase and the requested phase
in a XBL <handler>.  Doesn't seem to be related to this bug.
(In reply to comment #4)
> Weird... for my test case of nested phase="target" handlers, if there was no
> phase="target" handler on the target then the parent phase="target" fired...

That has to do with the original bug where the phase was always AT_TARGET. 
Shouldn't recreate with my patch.
(In reply to comment #5)
>you'll notice inconsistencies between the returned event.eventPhase and the
>requested phase in a XBL <handler>.  Doesn't seem to be related to this bug.
If you mean that phase="bubbling" and phase="capturing" fire on the target then
iirc the former is by design and the latter has a bug filed.

Also the patch does seem to fix the cases that didn't work before, although I am
still curious as to why my test case sometimes worked.
(In reply to comment #7)
> (In reply to comment #5)
> >you'll notice inconsistencies between the returned event.eventPhase and the
> >requested phase in a XBL <handler>.  Doesn't seem to be related to this bug.
> If you mean that phase="bubbling" and phase="capturing" fire on the target then
> iirc the former is by design and the latter has a bug filed.
> 
> Also the patch does seem to fix the cases that didn't work before, although I am
> still curious as to why my test case sometimes worked.

I guess what I meant to say, is that suppose that you have 
<form id="form1" class="clickHandler">
  <input type="button" value="Press Me" class="clickHandler"/>
</form>

and have clickHandler point to a XBL binding that does phase="capture" XBL event
handlers.  If you look at event.eventPhase inside the handler, it will come back
correctly as AT_TARGET when the button's capture handler fires first, but it
will show BUBBLING_PHASE when the form's capture handler fires next.  Like you
said, this is part of a known bug.  Just wanted to point out that this behavior
will still remain after my patch is applied.
Attachment #152633 - Flags: review?(bryner)
Comment on attachment 152633 [details] [diff] [review]
proposed fix v1

r+sr=bryner
Attachment #152633 - Flags: superreview+
Attachment #152633 - Flags: review?(bryner)
Attachment #152633 - Flags: review+
Checked in.

Checking in nsDOMEvent.cpp;
/cvsroot/mozilla/content/events/src/nsDOMEvent.cpp,v  <--  nsDOMEvent.cpp
new revision: 1.178; previous revision: 1.177
done
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: