1036357 - Wrong DOM event order / DOM specification violation

Status: RESOLVED INVALID

(Core :: DOM: Events, defect)

Description

[hyperbolic]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 (Beta/Release)
Build ID: 20140605174243

Steps to reproduce:

- Create an XHTML (strict) document
- Put a form field (input) somewhere into the document, using the following code: <input name="txt_Email" type="text" maxlength="50" />
- Include a JavaScript into the document (e.g. from an external file) with the following content:

function BlurHandler(event) {
  
  console.log(event.target);
  console.log(event.currentTarget);
  console.log(event.eventPhase);
  console.log();
}

function Init() {
  document.addEventListener("blur", BlurHandler, true);
}

window.addEventListener("load", Init, false);

- Let your web server serve the document as mime type application/xhtml+xml
- Open the document in FF 30
- Open the Console (Web Developer Tools)
- Reload the document
- Click into the form field (input), wait until you see the cursor blink there
- Click somewhere outside the browser window (e.g. activate another application)



Actual results:

The console now shows the following text lines:

<input type="text" name="txt_Email" maxlength="50">
HTMLDocument → http://mealert.home.omeganet.de/de/register.xhtml
1

HTMLDocument → http://mealert.home.omeganet.de/de/register.xhtml
HTMLDocument → http://mealert.home.omeganet.de/de/register.xhtml
2



Expected results:

Assuming that *one* blur event has been triggered:
event.target must not change while the event is going down the DOM tree.

Assuming that *two* blur events have been generated (one for document, one for the input field):
This behavior violates the DOM specification which clearly states that a capturing event handler must not be triggered by events dispatched directly to the EventTarget upon which it is registered. Thus, the handler should not have been triggered on the document object.

Being no DOM expert, I don't know (yet) which one of the assumptions is true. Since both of them (IMHO) show a bug, it doesn't make a difference.

By the way, IE and Chrome (updated to the most recent versions as of time of this writing) work like expected in this case.

Comment 1

[hyperbolic]

Correction of "expected results":

Assuming that *one* blur event has been triggered:
event.target must not change while the event is going down the DOM tree.
Furthermore, the order would be wrong: Ignoring that the handler must not be called on the document target itself (see below), it should have been called with document target first and then with input field target.

Assuming that *two* blur events have been generated (one for document, one for input field):
This behavior violates the DOM specification which clearly states that a capturing event handler must not be triggered by events dispatched directly to the EventTarget upon which it is registered. Thus, the handler should not have been triggered on the document object.

Comment 2

[hyperbolic]

Not sure why you have tagged this "testcase-wanted" ... I have described in detail how to reproduce. Could you please give me an advice what I should provide exactly (sorry for being a novice with bugzilla)?

Comment 3

[Robert Longson [:longsonr]]

Use the add an attachment button above to add an xhtml file that demonstrates the issue.

Comment 4

[hyperbolic]

Attachment: XHTML source with JavaScript included (test case)

This is an XHTML source with inlined JavaScript code which shows the problem I have described. From within FF, you can just open that file directly from the file system to observe that behavior.

Comment 5

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

(In reply to hyperbolic from comment #1) 
> Assuming that *two* blur events have been generated (one for document, one
> for input field):
> This behavior violates the DOM specification which clearly states that a
> capturing event handler must not be triggered by events dispatched directly
> to the EventTarget upon which it is registered.
Where do you get this? Capturing event listeners are called on target too.
http://dom.spec.whatwg.org/#concept-event-listener-invoke


And yes, there can be more than one blur event. For input, document, and even for the window.

Comment 6

[hyperbolic]

I am getting this from W3C's specifications:
http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-flow-capture

Please note the last sentence in the second paragraph of that section. Citing it: "A capturing EventListener will not be triggered by events dispatched directly to the EventTarget upon which it is registered."

Not having studied the source you have mentioned yet, I'd like to know which reference is authoritative: Yours or the W3C's?

Comment 7

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

DOM(In reply to hyperbolic from comment #6)
> I am getting this from W3C's specifications:
> http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-flow-capture
> 
That is an obsolete version of the spec.

> Not having studied the source you have mentioned yet, I'd like to know which
> reference is authoritative: Yours or the W3C's?
WhatWG's DOM is the spec most browsers try to implement.
(Microsoft may refer to the W3C version of the DOM spec
http://w3c.github.io/dom/#dispatching-events )

Comment 8

[hyperbolic]

OK, thanks for the clarification. Very worrying ...

Well, then obviously two blur events are generated in this case: One for the input field, one for the document. Both are captured by the document's event listener.

I think this bug could be closed since I have used the wrong reference. But I am still wondering why Chrome behaves differently (only one event is generated, the document's event listener triggers only once). IE also behaves differently (but you already have explained the reason).

One more question (if it's appropriate to answer in a bug report): How can I know how many events are generated for certain user action, and in which order?