Closed Bug 1584963 Opened 2 months ago Closed Last month

ValidityState reports invalid patternMismatch for an auto-filled valid "pattern"

Categories

(Core :: DOM: Editor, defect, P2)

defect

Tracking

()

VERIFIED FIXED
mozilla71
Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- wontfix
firefox67 --- wontfix
firefox68 --- wontfix
firefox69 --- wontfix
firefox70 --- wontfix
firefox71 --- verified

People

(Reporter: pascal, Assigned: masayuki)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0

Steps to reproduce:

Go to https://jsfiddle.net/3ubdye4j/
Enter 1234, and submit form (press enter)
Go to https://jsfiddle.net/3ubdye4j/ again
Choose suggested value "1234" (auto-fill)

Actual results:

"1234", "Please match the requested format."

Expected results:

"1234", ""

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0

Hi,

I have tested your issue on latest FF release 69.0.1 and latest Nightly build 71.0a1 (2019-10-03) and could not reproduce it using Ubuntu 18.04 and Windows 10.
My result is the same like the expected result from previous comment after submit the form second time with auto-fill.

If the issue is still reproducible on your end, can you please retest this using latest FF release and latest Nightly build (https://nightly.mozilla.org/) and report back the results? When doing this, please use a new clean Firefox profile (https://goo.gl/AWo6h8), maybe even safe mode (https://goo.gl/AR5o9d), to eliminate the possible causes.

Thanks for the report.

Flags: needinfo?(pascal)

Hum, i described something different from what i tested /o\

Go to https://jsfiddle.net/3ubdye4j/
Enter 1234, and submit form (press enter)
Go to https://jsfiddle.net/3ubdye4j/ again
Enter 1, then choose suggested value "1234" (auto-fill)

On my debian icewm:

On other OSes:

  • it reproduces on firefox 69.0.1 on Ubuntu 18.04.3
  • it reproduces on firefox 69.0.1 on a MacOS 10.14.6
Flags: needinfo?(pascal)

I have managed to reproduce the issue following the new updates from comment 2. I missed the part that I need to Enter 1 again, and just after that choose suggested value "1234" (auto-fill)
So, after submitting the form for the first time and then go again to https://jsfiddle.net/3ubdye4j/ , if just click on the form without entering "1" and choose suggested value "1234" (auto-fill) it works ok, the result is the expected result: "1234", "".
If go again to the page after submitting the form for the first time, type 1 and only after that choose suggested value "1234" (auto-fill), the result is: "1234", "Please match the requested format."

This is a regression, here is the pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=fbebc15cd4f40f0978bf22def0fcf355ce69f27b&tochange=824bcd08c85e70d98109b04715b26f139e099ce8

@Masayuki, can you please take a look over this?

Thanks.

Status: UNCONFIRMED → NEW
Component: Untriaged → DOM: Events
Ever confirmed: true
Flags: needinfo?(masayuki)
Keywords: regression
OS: Unspecified → All
Product: Firefox → Core
Hardware: Unspecified → All
Version: 69 Branch → Trunk

Masayuki, could we get a status update on this bug please? Thanks

Ah, okay, perhaps I got it.

Assignee: nobody → masayuki
Status: NEW → ASSIGNED
Component: DOM: Events → Editor
Flags: needinfo?(masayuki)
Priority: -- → P2

status-firefox-esr68: --- → wontfix

Really? I think that we should take this.

When nsTextEditorState::SetValue() is called with eSetValue_BySetUserInput,
we emulate user input. I.e., keep using transaction manager of the editor,
events fired while handling user input should be fired.

Currently, nsTextEditorState::SetValue() suppresses multiple state handling
while setting value with calling mTextListener->SettingValue(true). This
is why "input" event listeners cannot retrieve the latest state of validation
if inputType is "insertReplacementText".

This patch makes it keep managing mTextListener when setting the value
programatically. Otherwise, i.e., it emulates user input, editor should
manage it from EditorBase::NotifyEditorObservers() instead so that this
patch makes it not managing mTextListener in such case.

Pushed by masayuki@d-toybox.com:
https://hg.mozilla.org/integration/autoland/rev/f809ef4ac994
Make `nsTextEditorState` not manage `TextInputListener` by itself when chrome script emulates user input r=m_kato
Status: ASSIGNED → RESOLVED
Closed: Last month
Resolution: --- → FIXED
Target Milestone: --- → mozilla71

Verified - fixed on latest Nightly 71.0a1 (2019-10-20)(64-bit) (Build id: 20191020214712) on Windows 10 and Ubuntu 18.04.

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.