1947143 - openclassrooms.com - Unable to type date of birth

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect, P1)

Description

[Calin Tanase]

Environment:
Operating system: Android 15
Firefox version: Firefox Mobile [phone]

Steps to reproduce:

1. Go to https://openclassrooms.com/fr/register/email?_target_path=/application/welcome?skipWelcome=true&appsource=generic
2. At "Date de naissance" field, try typing a date.

Expected Behavior:
Date of birth can be typed.

Actual Behavior:
Unable to type.

Notes:

• Reproduces regardless of the status of ETP
• Reproduces in firefox-nightly, and firefox-release
• Does not reproduce in chrome

Created from https://github.com/webcompat/web-bugs/issues/147885

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.

Comment 2

[Sean Feng [:sefeng211]]

I think this is a site-bug or rather a framework bug in mui. I've filed an issue to them https://github.com/mui/mui-x/issues/16722, so let's see how it goes.

Comment 3

[Sean Feng [:sefeng211]]

MUI's maintainer couldn't reproduce it with a minimal testcase, and I also don't have enough knowledge about React + MUI to help them further. I wonder maybe if we contact the site author, they may have interests in collaboration?

Comment 4

[Lukas Tyla]

Hello, I wanted to provide a bit more context about why and when this happens.
We have explored the cause and identified that it is only happening on Firefox of all major mobile browsers (Safari and Chrome don't cause such issues).
Here is a comment with more specifics.

Also providing a copy paste of the comment:

The problem could be related to how Firefox controls the keyboard.
@shirRefundco could you clarify if a numeric or text (regular messaging) keyboard is open when you experience this issue?
Chrome on Android always opens "numeric" keyboard when requested and works without problems.

Locally forcing numeric inputMode avoids this problem.

So, Firefox on Android is unhappy about the dynamically changing inputMode (it changes to numeric only after a numeric section is focused).

---

I would appreciate it if you could please kindly check if there might be missing logic in dynamically reacting to inputMode attribute updates. 🙏

Comment 5

[Sean Feng [:sefeng211]]

Makoto, thought about this?

Comment 6

[Makoto Kato [:m_kato]]

Related to bug 1670129. I have to re-check whether InputConnection in GeckoView is updated, and Windows behavior...

Comment 7

[Makoto Kato [:m_kato]]

Ah, here. https://searchfox.org/mozilla-central/rev/9c395b6371eaea0d15f9c8a37889022be350cf0b/widget/android/GeckoEditableSupport.cpp#1492-1499

Comment 8

[Makoto Kato [:m_kato]]

https://treeherder.mozilla.org/jobs?repo=try&revision=3a4865a59dd245a74d3dd769903ca7d8d8da3812

Comment 9

[Sean Feng [:sefeng211]]

(I marked this as a site bug because originally the issue was about the focus not moving to the correct section, however I can't reproduce this anymore, and the IME issue that Makoto is fixing seems to be the only issue left)

(So this turns to be a platform-bug)

Comment 10

[Makoto Kato [:m_kato]]

Attachment: Bug 1947143 - Reset InputConnection when any input properties are changed. r=#geckoview-reviewers

We avoid to reset InputConnection not to erase IME's composing text
for some situations such as element.focus() call.

When changing inputmdoe during user interaction, we should reset
InputConnection to change keyboard layout.

Also, I add an API to emulate user interaction to write a test for
this issue.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7b461d976ec9
Reset InputConnection when any input properties are changed. r=geckoview-reviewers,ohall

Comment 12

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/7b461d976ec9

Comment 13

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:m_kato, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox137 to wontfix.

For more information, please visit BugBot documentation.

Comment 14

[Raul Bucata]

Verified as still reproducible using RC Build fenix android-arm64-v8a. The JJ field does not accept input, causing breakages. I was able to introduce data to the MM and AAAA field, but JJ is still broken most to the times

Tested with:

Browser / Version: Firefox 138.0 Build 2016086490
Operating System: Google Pixel 3 (Android 12) -1080 x 2160 pixels, 18:9 ratio (~443 ppi density)
Operating System: Oppo Find X5 (Android 13) - 1080 x 2400 pixels, 20:9 ratio (~402 ppi density)

Comment 15

[Raul Bucata]

Attachment: RC build reproducible

Comment 16

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

(In reply to Raul Bucata from comment #14)

Verified as still reproducible using RC Build fenix android-arm64-v8a. The JJ field does not accept input, causing breakages. I was able to introduce data to the MM and AAAA field, but JJ is still broken most to the times

Tested with:

Browser / Version: Firefox 138.0 Build 2016086490
Operating System: Google Pixel 3 (Android 12) -1080 x 2160 pixels, 18:9 ratio (~443 ppi density)
Operating System: Oppo Find X5 (Android 13) - 1080 x 2400 pixels, 20:9 ratio (~402 ppi density)

Hi Makoto, can you please take a look again? Thank you.

Comment 17

[Makoto Kato [:m_kato]]

Hmm, rarely I cannot input this edit form. I doesn't know what trigger. But I will look it again.

Comment 18

[Holger Benl [:hbenl]]

I can reproduce reliably by clicking on the JJ or the MM field and then pressing the "0" key. This key and all subsequent ones are ignored.

Comment 19

[Holger Benl [:hbenl]]

I may have found the root cause:
When the user clicks on one of the fields (JJ, MM or AAAA) in the date input, the selection range of the input is set to that field (useFieldV6TextFields.js line 105).
The next key press will replace the selected text with the character that was pressed (for example "JJ/MM/AAAA" turns into "5/MM/AAAA", this value is then normalized to "05/MM/AAAA" and written back to the date input).
After pressing "0", it still looks like the field is selected but the next key presses will be appended to the value of the selected field instead of replacing it (so "JJ/MM/AAAA" turns into "JJ5/MM/AAAA") and I guess that confuses the site's code.
You can observe this by putting a logpoint on line 225 of useFieldV6TextFields.js with the expression event.target.value.
On Chrome the selected field is always replaced, never appended to.

Comment 20

[Holger Benl [:hbenl]]

The behavior of mobile browsers (both Firefox and Chrome) regarding the effect that input.setSelectionRange() has on the result of the next key press is very inconsistent.
Go to https://hbenl.github.io/test/input-set-selection-range/, click on the input, enter some characters and look at the values that the oninput handler sees. On desktop browsers this is consistent - the selected range is replaced by the character that was entered, but on mobile browsers the behaviour is rather chaotic.

Comment 21

[Makoto Kato [:m_kato]]

At finally, GeckoEditable (java) and Gecko have different editable text result, so updating text doesn't notify to java side correctly. Although Gecko's IME state manager optimizes text and selection change, GeckoView wants the text/selection result after dispatching selection change and keyboard/composition event. But due to optimization, widget/GeckoEditableSupport won't receive it. Since Gecko main thread and Android's input thread is different, we have to sync it. But unfortunately, this seems not to sync it.

Comment 22

[Makoto Kato [:m_kato]]

Like :hbenl says, before inputting a character, selection change occurs by script. This might be trigger for this, but we try to change text, but content script rejects this then, it sets unmodified text.

05-22 23:36:17.885 16531 16585 I Gecko   : [Child 16531: Main Thread]: D/GeckoEditableSupport IME: NOTIFY_IME_OF_SELECTION_CHANGE: SelectionChangeData={ mOffset=2, mString="" (Length()=0), GetWritingMode()=h-ltr, mReversed=false, mCausedByComposition=false, mCausedBySelectionEvent=true, mOccurredDuringComposition=false }
05-22 23:36:17.888 16531 16585 I Gecko   : [Child 16531: Main Thread]: D/GeckoEditableSupport IME: Flush selection change: selStart=2, selEnd=2, causedOnlyByComposition=false
05-22 23:36:17.889 16531 16585 I Gecko   : [Child 16531: Main Thread]: D/GeckoEditableSupport IME: OnKeyEvent: aAction=0
05-22 23:36:17.889 16531 16585 I Gecko   : [Child 16531: Main Thread]: D/GeckoEditableSupport IME: IME_REPLACE_TEXT: aStart=0, aEnd=2, aText="0", mIMERanges=0, mIMEKeyEvents=2
05-22 23:36:17.889 16531 16585 I Gecko   : [Child 16531: Main Thread]: D/GeckoEditableSupport IME: Current selection: { mOffset=2, mData="" (Length()=0), Length()=0, EndOffset()=2 }
05-22 23:36:17.904 16531 16585 I Gecko   : [Child 16531: Main Thread]: D/GeckoEditableSupport IME: NOTIFY_IME_OF_TEXT_CHANGE: TextChangeData={ mStartOffset=0, mRemoveEndOffset=10, mAddedEndOffset=10, mCausedOnlyByComposition=false, mIncludingChangesDuringComposition=false, mIncludingChangesWithoutComposition=true }
05-22 23:36:17.905 16531 16585 I Gecko   : [Child 16531: Main Thread]: D/GeckoEditableSupport IME: NOTIFY_IME_OF_SELECTION_CHANGE: SelectionChangeData={ mOffset=0, mString="JJ" (Length()=2), GetWritingMode()=h-ltr, mReversed=false, mCausedByComposition=false, mCausedBySelectionEvent=false, mOccurredDuringComposition=false }
05-22 23:36:17.907 16531 16585 I Gecko   : [Child 16531: Main Thread]: D/GeckoEditableSupport IME: OnKeyEvent: aAction=1
05-22 23:36:17.908 16531 16585 I Gecko   : [Child 16531: Main Thread]: D/GeckoEditableSupport IME: Flush text change: text="JJ/MM/AAAA", start=0, unboundedOldEnd=10, unboundedNewEnd=10, causedOnlyByComposition=false
05-22 23:36:17.908 16531 16585 I Gecko   : [Child 16531: Main Thread]: D/GeckoEditableSupport IME: Flush selection change: selStart=0, selEnd=2, causedOnlyByComposition=false

After this, browser try to change text by input event, content script override unmodified text.

05-22 23:39:28.657 16531 16585 I Gecko   : [Child 16531: Main Thread]: D/GeckoEditableSupport IME: OnKeyEvent: aAction=0
05-22 23:39:28.657 16531 16585 I Gecko   : [Child 16531: Main Thread]: D/GeckoEditableSupport IME: IME_REPLACE_TEXT: aStart=2, aEnd=2, aText="1", mIMERanges=0, mIMEKeyEvents=2
05-22 23:39:28.658 16531 16585 I Gecko   : [Child 16531: Main Thread]: D/GeckoEditableSupport IME: Current selection: { mOffset=0, mData="'J' (0x004A) 'J' (0x004A)" (Length()=2), Length()=2, EndOffset()=2 }
05-22 23:39:28.669 16531 16585 I Gecko   : [Child 16531: Main Thread]: D/GeckoEditableSupport IME: NOTIFY_IME_OF_TEXT_CHANGE: TextChangeData={ mStartOffset=0, mRemoveEndOffset=10, mAddedEndOffset=10, mCausedOnlyByComposition=false, mIncludingChangesDuringComposition=false, mIncludingChangesWithoutComposition=true }
05-22 23:39:28.672 16531 16585 I Gecko   : [Child 16531: Main Thread]: D/GeckoEditableSupport IME: OnKeyEvent: aAction=1
05-22 23:39:28.674 16531 16585 I Gecko   : [Child 16531: Main Thread]: D/GeckoEditableSupport IME: Flush text change: text="JJ/MM/AAAA", start=0, unboundedOldEnd=10, unboundedNewEnd=10, causedOnlyByComposition=false
05-22 23:39:28.674 16531 16585 I Gecko   : [Child 16531: Main Thread]: D/GeckoEditableSupport IME: Flush selection change: selStart=0, selEnd=2, causedOnlyByComposition=false

We need to investigate content script, but this seems to be react code. Hmm....

Comment 23

[Holger Benl [:hbenl]]

We need to investigate content script, but this seems to be react code. Hmm....

Bug 1964660 contains a much simpler reproduction case (https://hbenl.github.io/test/input-set-selection-range/).

Comment 24

[Makoto Kato [:m_kato]]

(In reply to Holger Benl [:hbenl] from comment #23)

We need to investigate content script, but this seems to be react code. Hmm....

Bug 1964660 contains a much simpler reproduction case (https://input-set-selection-range.glitch.me/).

As long as I test, this occurs when inputting "0". Also, I cannot reproduce this issue with https://mui.com/x/react-date-pickers/date-field/. It might be fixed by https://github.com/mui/mui-x/pull/17816.

Comment 25

[Lukas Tyla]

I have tested a minimal reproduction case (on Android Firefox 138.0.4) I have created with an older version of MUI Date Pickers: https://react-ejos7qxt.stackblitz.io/, and it looks like the original problem is gone - the keyboard correctly changes to numeric.
You can play around with the demo in the StackBlitz.

Also, I cannot reproduce this issue with https://mui.com/x/react-date-pickers/date-field/. It might be fixed by https://github.com/mui/mui-x/pull/17816.

The mentioned documentation is now running on v8, which by default renders an accessible field (composite component with multiple spinbutton elements), to properly test the issue on the plain docs examples, please use the v7 documentation or the example I linked above. 😉

I haven't delved into the issue in depth, but to me the original problem seems resolved. 👍

Comment 26

[Makoto Kato [:m_kato]]

I verified after landing bug 1964660