1323815 - moving focus to <input type="number" /> blur event occurs with corrupted event.relatedTarget

Status: RESOLVED FIXED

(Core :: DOM: Events, defect)

Description

[Romk]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20161208153507

Steps to reproduce:

I listen blur events at capturing phase on a container;
I have a link within the container and an input with type="number" next to the container.
Pressing tab focus moves to the input and event gets fired.
At this step I do check:

if (!event.relatedTarget ||
    !(event.relatedTarget instanceof window.Node) ||
    !container.contains(event.relatedTarget)) {
    doStuff();
}


Actual results:

TypeError: Argument 1 of Node.contains does not implement interface Node.

Logging the event.relatedTarget outputs
<input tabindex="0" type="text">

Logging the event.relatedTarget == document.querySelector('[type="number"]') outputs
false

Checks like
event.relatedTarget instanceof window.Node
event.relatedTarget instanceof window.Element
event.relatedTarget instanceof window.HTMLElement
all return true.

event.relatedTarget.tagName leads to
Error: Permission denied to access property "tagName"


Expected results:

event.relatedTarget should be the actual HTMLElement, which I get with document.querySelector('[type="number"]')

Comment 1

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

Could you please attach a _minimal_ testcase using the 'Add an attachment' link?

Comment 2

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

...but I think I see where the issue is.

Comment 3

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

nm, no need to attach a testcase.

Comment 4

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

Attachment: patch

Hmm, what happened. I thought I attached this already last night.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=4b88f2ae136c1eaf3b853c055eb07305737c6279

make focusevent's relatedTarget be handled like mouseEvent's relatedTarget.
The Shadow DOM part isn't super important atm, since it is for the disabled v0 Shadow DOM.
But I still moved the FindFirstNonChromeOnlyAccessContent to happen earlier, so that we don't end up
overriding relatedTarget from shadom DOM handling part if ChromeOnlyAccess returns true.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/77d22efb44b1
FocusEvent.relatedTarget should work consistently with MouseEvent.relatedTarget, r=masayuki

Comment 6

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/77d22efb44b1