I cannot reproduce this issue. Here is an example test page which worked. Slightly different from what you have regarding the creation of the element.

https://output.jsbin.com/hakituzozi

Reporter, if you still see the issue could you provide a live test page and instructions how to reproduce the issue?

Able to reproduce in all version of Chrome since at least 23.
Simplified test.html attached, it displays OK or FAIL.
Relevant spec section: https://dom.spec.whatwg.org/#dispatching-events

Debugged to https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/dom/events/event_dispatcher.cc?l=356&rcl=cd53b6f54660635abec092b800714e5d6a131186

  // 16. If target's root is a shadow root, then set event's target attribute
  // and event's relatedTarget to null.
  event_->SetTarget(event_->GetEventPath().GetWindowEventContext().Target());

It seems to always set the target to null.
When I comment this line, the test passes.

Deleted: test.html 417 bytes

test.html 417 bytes View Download

Hello,

For the first comment, I think you appended the element to the document. In my case, the element was not added in dom tree.

For the second comment, If it's always set to null, then why I'm getting a target at 1st breakpoint? Please try to add a breakpoint at both console.log, and you'll see it has a target at 1st breakpoint and the target is set to null at 2nd breakpoint.

Thank you

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

"It's always set to null" in the second comment means "at the second breakpoint" i.e. when the event handler has already completed.

Thank you very much for answering. I read the spec but not sure if i understood it correctly. I think this rule might be what you were referring to:

/*
10. If clearTargets, then:

    1. Set event’s target to null.

    2. Set event’s relatedTarget to null.

    3. Set event’s touch target list to the empty list.
*/

Could you explain a bit about it? I guess maybe the element that is not added to the dom tree will be added to the shadow root?

Also could you tell me why others browsers don't set the target to null with   the same code?

Thank you

Well, to me it's an obvious bug in Chrome.
Let's wait for the actual @chromium developers.

OK thank you for reply!

Able to reproduce the issue on Mac 10.13.3, Win-10 and Ubuntu 17.10 using chrome reported version #67.0.3396.87 and latest canary #69.0.3479.0.
This is a non-regression issue as it is observed from M60 old builds. 

Hence, marking it as untriaged to get more inputs from dev team.

Thanks...!!

hayato@ could you look at
https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/dom/events/event_dispatcher.cc?l=356&rcl=cd53b6f54660635abec092b800714e5d6a131186

which you added a few years ago. I was wondering what the expectation here is when the element is created like in this bug but doesn't belong to any document.

> which you added a few years ago. I was wondering what the expectation here is when the element is created like in this bug but doesn't belong to any document.

Thanks for the investigation. This is a good point. I'll take a look.

rakina@, you might want to take a look at this issue.

I think this  http://crbug.com/775838 / is not directly related, but you might be interested in this issue too.

cc-ing: kochi@ too, regarding https://bugs.chromium.org/p/chromium/issues/detail?id=826702.

I guess you want to check again whether the current code matches the latest spec.
If possible, fix them at all. :)

Please feel free to re-assign me if you need my help.