1709027 - When using HTMLInputElement.setCustomValidity, messages stop appearing if I press "submit" while a validation message is onscreen

Status: VERIFIED FIXED

(Core :: DOM: Forms, defect)

Description

[simonmckenzie]

Attachment: Demonstration of broken setCustomValidity.gif

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:88.0) Gecko/20100101 Firefox/88.0

Steps to reproduce:

Visit this page: https://udacity.github.io/course-web-forms/lesson2/setCustomValidity/
Press submit once. A validation message appears
Press submit again, while the validation message is visible
Press submit as many times as you like afterwards :(

Actual results:

The validation message appeared the first time I pressed submit
Pressing it again while the message was visible did not show the message again, and then no more messages would appear

Expected results:

The validation message should show on each attempt to submit the form. Without this, the user can be left with an unsubmittable form with no feedback as to what's wrong.

For reference, Chrome will show the message on every submit.

Comment 1

[Jeronimo Torti (Please send NI request to Brindusa Tot)]

Hi simonmckenzie,
I was able to reproduce on Windows 10, on Firefox Nightly 90.0a1 (2021-05-13) (64-bit) version and Release 88.0.1 (64-bit) version.

I've assigned a component in order to get the dev team involved.
'Protections UI' team if it's not relevant, , please feel free to change the component if this is not the appropriate one.

Regards,
Jerónimo.

Comment 2

[Paul Zühlcke [:pbz]]

Not sure where this belongs exactly, but not in Protections UI for sure. I'll move it to DOM Forms. Please correct me if this is wrong.

Comment 3

[Hsin-Yi Tsai (she/her) [:hsinyi]]

I reproduced this issue back to builds on 2020-09-01. I never got the expected behavior as the reporter, i.e. no "validation message" every time when I submitted. I failed to get a regression window - could this behavior be here since the beginning? However, when I hovered the form, the validation message was displayed.

There was a slightly behavior change around 2021-02-22. Before 2021-02-22, when validation failed, the color of the border of the field was red. But it changed to blue.

Comment 4

[simonmckenzie]

Hi [:hsinyi],

I'm still able to reproduce this in the same way on Firefox 104.0.1 (64-bit) on https://udacity.github.io/course-web-forms/lesson2/setCustomValidity/ - each time I press submit, the message appears, unless I press it while the message is on screen. Once I've done that, I can't make the message appear again.

Comment 5

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Hsin-Yi Tsai (she/her) [:hsinyi] from comment #3)

I reproduced this issue back to builds on 2020-09-01. I never got the expected behavior as the reporter, i.e. no "validation message" every time when I submitted. I failed to get a regression window - could this behavior be here since the beginning?

Ah ha, okay, I got this regression window
https://hg.mozilla.org/mozilla-central/pushloghtml?changeset=1585337fe15cc6b7a1ddb20eca0e88edc637de21

Bug 1634046 looks suspicious to me. NI Gijs to take a look. Thanks.

However, when I hovered the form, the validation message was displayed.

There was a slightly behavior change around 2021-02-22. Before 2021-02-22, when validation failed, the color of the border of the field was red. But it changed to blue.

Comment 6

[:Gijs (he/him)]

(In reply to simonmckenzie from comment #0)

Press submit again, while the validation message is visible

For some reason this is breaking the logic in the code showing this popup. I don't really understand why off-hand. The logic, when it works, is roughly as follows:

1. if we've got a panel, assume it's visible and do not move or reshow it.
2. if we don't have a panel, create one, add a listener to it that fires when the panel hides, and show the panel.
3. once the panel hides, clean up the reference to the panel
4. at the next attempt to show the panel, repeat - the panel reference should be cleared and so we'll reshow the panel.

When things break, somehow the popuphiding event listener does not fire and the reference to the panel sticks around instead of being cleared, thereby stopping us from ever showing the panel again.

I don't really understand why this event is not firing in the specific case where the user submits the form while the panel is up.

The wallpaper solution is likely to be having previouslyShown be also true if the panel exists but is hidden, by changing this line:

https://searchfox.org/mozilla-central/rev/25ec642ed33ca83f25e88ec0f9f27e8ad8a29e24/browser/actors/FormValidationParent.jsm#151

to be something like let previouslyShown = this.panel && this.panel.state != "closed" or something along those lines.

But that's not very satisfactory... I also don't know how any of this relates to the regressing patch. Perhaps we're not firing the event if the panel has never received a frame, or something, and that breaks the logic here - and it didn't use to because we wrote to panel.hidden = false which may have forced layout in some way? Emilio, do you have any idea what's happening here?

Comment 7

[Emilio Cobos Álvarez (:emilio)]

I can't repro this on Linux at all, and on Windows comment 6 doesn't quite seem to be what's happening. I think this has to do with the panel animations. If I dump stuff on Windows, I get:

receiveMessage(FormValidation:ShowPopup, null)
_showPopup(null)
calling openPopupAtScreenRect(closed)
handleEvent(popuphiding, [object XULPopupElement])
_onPopupHiding(invalid-form-popup)
receiveMessage(FormValidation:HidePopup, null)
receiveMessage(FormValidation:ShowPopup, null)
_showPopup(null)
calling openPopupAtScreenRect(hiding)

The issue is that that openPopupAtScreenRect on a popup that hasn't finished hiding (it's in the hiding, not hidden / closed state) is not showing the popup, so it breaks our logic.

There are two potential fixes here afaict:

• Listening to popuphidden as well to ensure we also clean up after ourselves.
• Keeping _panel non-null until popuphidden (similar idea).

But basically the crux of the problem is that hiding the popup is effectively not synchronous due to panel animations.

Comment 8

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1709027 - Listen to popuphidden in FormValidationParent. r=Gijs

This ensures that by the time we null out this._panel, we can call openPopup
again properly, which the opening code relies on.

Comment 9

[Daniel Bodea [:danibodea]]

This is definitely a regression between:

• First known bad: Tested mozilla-central build: 2020-06-03 (verdict: b)
• Last known good: Tested mozilla-central build: 2020-06-02 (verdict: g)

Mozregression would not go further considering these old builds so this is the best regression range I can provide.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6fbacc7bb20a
Listen to popuphidden in FormValidationParent. r=Gijs

Comment 11

[Cristina Cozmuta (:CrissCozmuta)]

https://hg.mozilla.org/mozilla-central/rev/6fbacc7bb20a

Comment 14

[Ardelean Oana, Desktop QA [:oardelean]]

I managed to reproduce this issue on Firefox 105.0(build ID: 20220912145803) on Windows 10 using the STR and URL from the Description. Verified as fixed on Firefox 106.0b7(build ID: 20221002185807) and Nightly 107.0a1(build ID: 20221003212025) on Windows 10, Windows 11, macOS 12. Ubuntu seems to be unaffected.