764589 - Input:focus with relative position does not fire click event

Status: NEW

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[jason]

Attachment: input.html

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0
Build ID: 20120601045813

Steps to reproduce:

Created an input that changes its position to relative upon focus. If position: relative; is removed from the :focus styling the click event fires as expected.


Actual results:

Click event did bubble up the DOM as expected.


Expected results:

Expected click event to fire.

Comment 1

[jason]

Not sure if #652531 may be related, but it looks fairly similar to this.

Comment 2

[Victor Homyakov]

Looks like duplicate of bug 493416

Comment 3

[Abe - QA (:Abe_LV)]

Attachment: event.PNG

Comment 4

[Abe - QA (:Abe_LV)]

Attachment: event.PNG

User Agent 	Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:46.0) Gecko/20100101 Firefox/46.0
Version 	46.0a1
Build ID 	20160112030207
Channel 	nightly

Jason,
Thank you for taking time to report this.
Are you still able to reproduce this in the latest version ? I attached what I see in the console window for the html given above.

Comment 5

[jason]

Abe,

I'm still able to replicate this on nightly.

User Agent    Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:46.0) Gecko/20100101 Firefox/46.0
Version       46.0a1 (2016-01-15)
Build ID      20160115030235

To clarify, the issue happens only when you click on the input for it's initial focus. Subsequent clicks after the input already fire the click event correctly, as well as when you click anywhere else on the body.

Comment 6

[jason]

Sorry, meant to say "Subsequent clicks after the input already has focus fire the click event correctly"

Comment 7

[Abe - QA (:Abe_LV)]

User Agent    Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:46.0) Gecko/20100101 Firefox/46.0
Version       46.0a1 (2016-01-15)
Build ID      20160121030235
Channel       nightly

Yes, I can reproduce this. The first click does not fire the click event.

Comment 8

[Andrew Overholt [:overholt]]

smaug, what do you think?

Comment 9

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

Yeah, I'm pretty sure the issue is that we recreate the frame for the input and don't detect the mouseup happens on the same element.

Comment 10

[Jeremy Spurlin (MS)]

I've noticed that this also happens when setting float (instead of position). Additionally, changing those attributes (or even just setting content: "") on focus for :before/:after pseudo elements also exhibits this behavior.