Mouse events seem broken on first click of inputs are marked for form autofill
Categories
(Toolkit :: Form Autofill, defect, P1)
Tracking
()
| Webcompat Priority | revisit |
People
(Reporter: twisniewski, Assigned: tgiles)
References
Details
(Keywords: regression, testcase)
Attachments
(1 file)
|
269 bytes,
text/html
|
Details |
The attached test-case has three basic inputs with the ids txtPostalCode, txtFirstName, and txtLastName. This combination of inputs does not receive any mouse events the first time the user clicks on them (though subsequent clicks do show the events).
To me this would imply that we have some sort of click-jacking protection or form autofilling getting in the way of the first events. But since Chrome does not do this, it can cause noticable webcompat issues, as reported here: https://webcompat.com/issues/28273
|
Reporter | |
Comment 1•5 years ago
|
||
MattN, do you maybe have any ideas about this?
|
||
Comment 2•5 years ago
•
|
||
Can you reproduce the problem if you set the pref extensions.formautofill.available to "off" and then restart Fx? We do initialization of Form Autofill on the first click inside a relevant field so it's possible we're interfering with the site's event.
|
|
||
Comment 3•5 years ago
|
||
Disabling autofill with the step in comment 2 does fix it for me. I don't see any stopPropagation/preventDefault/return false that would be affecting content events though…
|
|
||
Comment 4•5 years ago
|
||
Hmm… this might be related to nsFormFillController::MarkAsAutofillField getting called since that doesn't get called the times when it works. Maybe that is interacting with the focus manager in the middle of the event handling in a weird way:
https://searchfox.org/mozilla-central/rev/f8b11433159cbc9cc80500b3e579d767473fa539/toolkit/components/satchel/nsFormFillController.cpp#329,331,333
|
|
Reporter | |
Comment 5•5 years ago
|
||
For the record: yes, setting extensions.formautofill.available to off also works for me (I just didn't realize I had to restart for that to take).
|
||
Updated•5 years ago
|
|
|
||
Comment 6•5 years ago
|
||
Regression range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5845151f1a2cd00957fdd48e204542ccbdfaba1e&tochange=2fba314d7de77ad8ab693a2ea0112c0cda5dd564
Nothing jumps out so far.
|
|
||
Comment 7•5 years ago
|
||
Since that regression range is so big it's not that helpful yet… instead I tried to just comment out the formFillController.markAsAutofillField(field); call and that fixes it.
|
|
||
Comment 8•5 years ago
|
||
The problem seems to be: https://searchfox.org/mozilla-central/rev/f8b11433159cbc9cc80500b3e579d767473fa539/dom/html/HTMLInputElement.cpp#2305-2307
// Reconstruct the frame to append an anonymous preview node
nsLayoutUtils::PostRestyleEvent(this, RestyleHint{0},
nsChangeHint_ReconstructFrame);
If I comment that out then the problem goes away.
heycam, does it make sense that the above code could break the handling of an onclick="" handler if it runs during a focusin event?
|
||
Comment 9•5 years ago
|
||
We've historically had certain event-related problems related to frame reconstructions. The one that comes to mind is <select> element popups not showing if you change a style property on :active that causes a frame reconstruction, although I can't find the bug right now.
<!DOCTYPE html>
<style>
input:active { position: relative; }
</style>
<input onclick="alert('hi')">
I haven't dug into that issue so I'm not sure what state tracking gets lost during the mouse down and detecting that we should be dispatching a click event. Maybe something in the event state manager? It notably doesn't happen for other elements, like a <div>.
|
||
Comment 10•5 years ago
|
||
:twisniewski, since this bug is a regression, could you fill (if possible) the regressed_by field?
For more information, please visit auto_nag documentation.
|
|
Reporter | |
Comment 11•5 years ago
|
||
I'm afraid that it's old enough that mozregression couldn't get a precise bug# for me on OSX, just the range:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e916ab827babb677ce5ab2cac0390c1401eaca0e&tochange=edb7e1ddd9b61e2af2a75cfe5baa0f92a54a2716
I'm not sure which of those is a candidate, however.
|
|
||
Comment 12•5 years ago
|
||
(In reply to Thomas Wisniewski [:twisniewski] from comment #11)
I'm afraid that it's old enough that mozregression couldn't get a precise bug# for me on OSX, just the range:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e916ab827babb677ce5ab2cac0390c1401eaca0e&tochange=edb7e1ddd9b61e2af2a75cfe5baa0f92a54a2716I'm not sure which of those is a candidate, however.
I'm not sure how you got a different range than I did in comment 6…
|
|
||
Updated•5 years ago
|
|
|
||
Comment 13•5 years ago
|
||
The priority flag is not set for this bug.
:MattN, could you have a look please?
For more information, please visit auto_nag documentation.
|
||
Comment 14•5 years ago
|
||
This is confirmed and seems to be in the right component at least for now, so I'll give it a priority to remove it from the triage list.
The patches on Bug 1370429 show in up the regression range from comment #6, and seem to be at least in the right ballpark to cause something like this?
OTOH, https://hg.mozilla.org/mozilla-central/rev/4b6fe4dc69e32e3d292386a976db64999addbfd1 from comment #11 looks suspicious too (to my uneducated eye) Apologies if that's just noise.
|
|
||
Updated•5 years ago
|
|
|
||
Updated•4 years ago
|
|
||
Updated•4 years ago
|
|
||
Updated•3 years ago
|
|
Assignee | |
Comment 15•3 years ago
|
||
I'm not able to reproduce this issue nor the linked webcompat issue on Nightly 96.
:twisniewski are you able to reproduce this? I have a feeling something fixed this between the original report and now
|
|
Reporter | |
Comment 16•3 years ago
|
||
Yes, thankfully this appears to have since been fixed, as both the testcase is working for me, as well as what was broken on the original site. Thanks for checking, Tim!
Description
•