1210253 - <input>s' validation message prevents first click on input content from happening

Status: NEW

(Core :: Layout: Form Controls, defect, P3)

Description

[arni2033]

STR:   (Win7_64, Nightly 44, 32bit, ID 20150930030231, new profile, safe mode)
1. Open the following "data:" url or click URL in the form above
>   data:text/html,<form><input type="email" autofocus/><input type="number"/><input type="submit"/>
2. Type "asdf" in the first input, press Enter   [validation message will appear]
3. Make sure cursor is blinking after "f". Click between "s" and "d"
4. Select all text in the first input, type "a@a".
5. Type "asdf" in the second input, press Enter   [validation message will appear]
6. Make sure cursor is blinking after "f". Click between "s" and "d"

Result:       The first click never happens if validation message is displayed
Expectations: As a result of Step 3 (and Step 6), cursor should be placed between "s" and "d"

Comment 1

[Brad Dunbar]

A slightly simpler example:

    data:text/html,<form><input type="email" autofocus required onclick="console.log('click')"/><input type="submit"/>

From what I can tell there is no event being triggered when clicking the invalid input.

Comment 2

[Mirko Brodesser (:mbrodesser-Igalia)]

Analysis so far: nsWindow::OnButtonPressEvent rolls up the validation message in nsWindow::CheckForRollup (https://searchfox.org/mozilla-central/source/widget/gtk/nsWindow.cpp#2569) and prevents it form dispatching the event to the editor. Hence, the caret doesn't move.

There seems to be a related problem: for instance when having the "Bookmarks" tab open and then directly clicking into an input field the caret doesn't move to the clicked position and no 'onclick' event is fired.

Comment 3

[Mirko Brodesser (:mbrodesser-Igalia)]

Mats: as the root cause of the problem doesn't seem to be in DOM code but rather in widget/gtk/ and likely in widget/windows/, does it make sense to take this bug over? If I can help with any information, please let me know.

Comment 4

[Mats Palmgren (inactive)]

Yeah, the underlying problem is likely in layout / widget code

Comment 5

[Emilio Cobos Álvarez (:emilio)]

Right, I guess changing that code will mean that clicking in a <select> element when the popup is open would not hide the popup ...

Comment 6

[Mats Palmgren (inactive)]

To be clear: that behavior is intentional for <select> (and other
menu-type things?), but we should probably not consume the event
in this case.