Closed Bug 1323815 Opened 5 years ago Closed 5 years ago

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

Categories

(Core :: DOM: Events, defect)

50 Branch
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla53
Tracking Status
firefox53 --- fixed

People

(Reporter: drp-works, Assigned: smaug)

Details

Attachments

(1 file)

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"]')
Could you please attach a _minimal_ testcase using the 'Add an attachment' link?
Flags: needinfo?(drp-works)
...but I think I see where the issue is.
Assignee: nobody → bugs
nm, no need to attach a testcase.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(drp-works)
Attached patch patchSplinter Review
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.
Attachment #8819268 - Flags: review?(masayuki)
Pushed by opettay@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/77d22efb44b1
FocusEvent.relatedTarget should work consistently with MouseEvent.relatedTarget, r=masayuki
https://hg.mozilla.org/mozilla-central/rev/77d22efb44b1
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla53
You need to log in before you can comment on or make changes to this bug.