Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

Textarea glitches with special characters after update

  • No replies
  • 0 have this problem
  • 25 views
more options

Hello, hope you're having a nice day.

I'm encountering an issue in my web app: when typing a character with an accent (such as á, ä, etc.), the textarea clears out and becomes disabled, making it unusable for Spanish speakers. This behavior worked correctly until a few months ago. The application is built with Vaadin.

Below are the mozregression logs for this issue. The commit that first showed this behavior is a24b524f, worked fine upto 3b954f08.

2025-09-17T08:58:01.828000: INFO : Narrowed integration regression window from [8ba9b64c, a24b524f] (4 builds) to [3b954f08, a24b524f] (2 builds) (~1 steps left) 2025-09-17T08:58:01.831000: DEBUG : Starting merge handling... 2025-09-17T08:58:01.832000: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=a24b524fe1b32a658d105df47dc723c9ec8e15d8&full=1 2025-09-17T08:58:01.832000: DEBUG : redo: attempt 1/3 2025-09-17T08:58:01.832000: DEBUG : redo: retry: calling _default_get with args: ('https://hg.mozilla.org/integration/autoland/json-pushes?changeset=a24b524fe1b32a658d105df47dc723c9ec8e15d8&full=1',), kwargs: {}, attempt #1 2025-09-17T08:58:01.833000: DEBUG : urllib3.connectionpool: Resetting dropped connection: hg.mozilla.org 2025-09-17T08:58:02.871000: DEBUG : urllib3.connectionpool: https://hg.mozilla.org:443 "GET /integration/autoland/json-pushes?changeset=a24b524fe1b32a658d105df47dc723c9ec8e15d8&full=1 HTTP/1.1" 302 0 2025-09-17T08:58:04.128000: DEBUG : urllib3.connectionpool: https://hg-edge.mozilla.org:443 "GET /integration/autoland/json-pushes?changeset=a24b524fe1b32a658d105df47dc723c9ec8e15d8&full=1 HTTP/1.1" 200 None 2025-09-17T08:58:04.133000: DEBUG : Found commit message: Bug 1941973 - Make `EditorBase::OnCompositionChange` always dispatch `input` event with a new pref r=m_kato

The reported web site in bug 1910865 sets `HTMLInputElement.value` to the latest value explicitly at every `input` event except when during a composition. When it's in a composition, it stores the latest value at `input` events during the composition and set it at `compositionend` event listener.

Currently, Gecko dispatches the events as the following order at ending a composition: 1. `beforeinput` whose `isComposing` is `true` 2. `compositionend` 3. `input` whose `isComposing` is `false`

Therefore, if user chooses the commit string from the candidate list, the commit string is not notified by `input` event before the `compositionend`.

On the other hand, Chrome dispatch the events as the following order: 1. `beforeinput` whose `isComposing` is `true` 2. `input` whose `isComposing` is `true` 3. `compositionend`

I.e., no `input` event is fired after `compositionend` and there is no `input` event whose `isComposing` is `false`. This is handled in the spec issue [1], but not yet resolved.

Perhaps, we can dispatch redundant `input` event before `compositionend` event, i.e., 1. `beforeinput` whose `isComposing` is `true` 2. `input` whose `isComposing` is `true` 3. `compositionend` 4. `input` whose `isComposing` is `false`

This breaks the pair of `beforeinput` and `input`, but I guess it's not important for web apps especially for the redundant `input` event case.

1. https://github.com/w3c/uievents/issues/202

Differential Revision: https://phabricator.services.mozilla.com/D234620

2025-09-17T08:58:04.134000: DEBUG : Did not find a branch, checking all integration branches 2025-09-17T08:58:04.134000: INFO : The bisection is done. 2025-09-17T08:58:04.134000: INFO : Stopped

Hello, hope you're having a nice day. I'm encountering an issue in my web app: when typing a character with an accent (such as á, ä, etc.), the textarea clears out and becomes disabled, making it unusable for Spanish speakers. This behavior worked correctly until a few months ago. The application is built with Vaadin. Below are the mozregression logs for this issue. The commit that first showed this behavior is a24b524f, worked fine upto 3b954f08. 2025-09-17T08:58:01.828000: INFO : Narrowed integration regression window from [8ba9b64c, a24b524f] (4 builds) to [3b954f08, a24b524f] (2 builds) (~1 steps left) 2025-09-17T08:58:01.831000: DEBUG : Starting merge handling... 2025-09-17T08:58:01.832000: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=a24b524fe1b32a658d105df47dc723c9ec8e15d8&full=1 2025-09-17T08:58:01.832000: DEBUG : redo: attempt 1/3 2025-09-17T08:58:01.832000: DEBUG : redo: retry: calling _default_get with args: ('https://hg.mozilla.org/integration/autoland/json-pushes?changeset=a24b524fe1b32a658d105df47dc723c9ec8e15d8&full=1',), kwargs: {}, attempt #1 2025-09-17T08:58:01.833000: DEBUG : urllib3.connectionpool: Resetting dropped connection: hg.mozilla.org 2025-09-17T08:58:02.871000: DEBUG : urllib3.connectionpool: https://hg.mozilla.org:443 "GET /integration/autoland/json-pushes?changeset=a24b524fe1b32a658d105df47dc723c9ec8e15d8&full=1 HTTP/1.1" 302 0 2025-09-17T08:58:04.128000: DEBUG : urllib3.connectionpool: https://hg-edge.mozilla.org:443 "GET /integration/autoland/json-pushes?changeset=a24b524fe1b32a658d105df47dc723c9ec8e15d8&full=1 HTTP/1.1" 200 None 2025-09-17T08:58:04.133000: DEBUG : Found commit message: Bug 1941973 - Make `EditorBase::OnCompositionChange` always dispatch `input` event with a new pref r=m_kato The reported web site in bug 1910865 sets `HTMLInputElement.value` to the latest value explicitly at every `input` event except when during a composition. When it's in a composition, it stores the latest value at `input` events during the composition and set it at `compositionend` event listener. Currently, Gecko dispatches the events as the following order at ending a composition: 1. `beforeinput` whose `isComposing` is `true` 2. `compositionend` 3. `input` whose `isComposing` is `false` Therefore, if user chooses the commit string from the candidate list, the commit string is not notified by `input` event before the `compositionend`. On the other hand, Chrome dispatch the events as the following order: 1. `beforeinput` whose `isComposing` is `true` 2. `input` whose `isComposing` is `true` 3. `compositionend` I.e., no `input` event is fired after `compositionend` and there is no `input` event whose `isComposing` is `false`. This is handled in the spec issue [1], but not yet resolved. Perhaps, we can dispatch redundant `input` event before `compositionend` event, i.e., 1. `beforeinput` whose `isComposing` is `true` 2. `input` whose `isComposing` is `true` 3. `compositionend` 4. `input` whose `isComposing` is `false` This breaks the pair of `beforeinput` and `input`, but I guess it's not important for web apps especially for the redundant `input` event case. 1. https://github.com/w3c/uievents/issues/202 Differential Revision: https://phabricator.services.mozilla.com/D234620 2025-09-17T08:58:04.134000: DEBUG : Did not find a branch, checking all integration branches 2025-09-17T08:58:04.134000: INFO : The bisection is done. 2025-09-17T08:58:04.134000: INFO : Stopped

You must log in to your account to reply to posts. Please start a new question, if you do not have an account yet.