2020927 - RichTextArea of GWT project is broken in Firefox 148

Status: VERIFIED FIXED

(Core :: DOM: Navigation, defect)

Description

[Tatu Lund]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36

Steps to reproduce:

We have observed that RichTextArea from GWT project is broken. We use the widget in older versions of Vaadin. The component worked ok with Firefox 147, but is broken in Firefox 148.

Actual results:

There is live demo here for you to check:

https://demo.vaadin.com/sampler/#ui/data-input/text-input/rich-text-area

Try to use e.g. Bold, Italic, etc. buttons. Observe that they do not work. This used to work in Firefox 147.

Expected results:

There seems to be some glitch with focus.

E.g. Bold button should first focus document window, which is in edit mode, and the executes toggle bold command.

If I pick the iframe in Firefox console as temp0 and the button element as temp1, I can do the following:

temp1.addEventListener('click', (e) => temp0.contentWindow.focus());
​
temp0.contentWindow.addEventListener('focus', (e) => { temp0.contentWindow.document.execCommand('Bold', false, 'false'); console.log('Toggled'); });
​
Which will work, i.e. when the toggle is done within the focus event, that works.

Also if I click edit area manually and then execute from console:

temp0.contentWindow.document.execCommand('Bold', false, 'false')

The toggling works

What the component does normally is equivalent of

temp1.addEventListener('click', (e) => { temp0.contentWindow.focus(); temp0.contentWindow.document.execCommand('Bold', false, 'false'); } );

And that is now failing in Firefox 148, but it was working in Firefox 147.

The weird thing is that I cannot workaround it with setTimeout function.

Comment 1

[Henri Sivonen (:hsivonen)]

See discussion in bug 2020668 and in https://github.com/gwtproject/gwt/issues/10292

Comment 2

[Henri Sivonen (:hsivonen)]

Attachment: Bug 2020927 - Extend the CKEditor 4 compat hack to GWT RichTextArea.

Comment 3

[Henri Sivonen (:hsivonen)]

Shippable-config builds for 64-bit Linux, Mac, and Windows coming up in https://treeherder.mozilla.org/jobs?repo=try&landoCommitID=183470

Comment 4

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

Set release status flags based on info from the regressing bug 543435

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/f221fdf5e4bc
https://hg.mozilla.org/integration/autoland/rev/df56ec35e76c
Extend the CKEditor 4 compat hack to GWT RichTextArea. r=emilio

Comment 6

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/df56ec35e76c

Comment 7

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

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

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox149 to wontfix.

For more information, please visit BugBot documentation.

Comment 8

[Donal Meehan [:dmeehan]]

Tracked for Fx148 release. To add to Comment 7, please also add a release uplift request

Comment 9

[Donal Meehan [:dmeehan]]

This may be too late for Fx148. It has not been uplifted to beta yet, and the planned Fx148 dot release builds tomorrow.

Comment 10

[Henri Sivonen (:hsivonen)]

Attachment: Bug 2020927 - Extend the CKEditor 4 compat hack to GWT RichTextArea. r=emilio

Comment 11

[Henri Sivonen (:hsivonen)]

Attachment: Bug 2020927 - Extend the CKEditor 4 compat hack to GWT RichTextArea.

Original Revision: https://phabricator.services.mozilla.com/D286099

Comment 12

[Henri Sivonen (:hsivonen)]

Attachment: Bug 2020927 - Extend the CKEditor 4 compat hack to GWT RichTextArea.

Original Revision: https://phabricator.services.mozilla.com/D286099

Comment 13

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined: The rich text editor component of GWT doesn't work in Firefox.

(Sorry about the large number of duplicate uplift requests for the dependency. The UI for this scenario is not great.)

• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing: On both https://demo.vaadin.com/sampler/#ui/data-input/text-input/rich-text-area and https://samples.gwtproject.org/samples/Showcase/Showcase.html#!CwRichText , test that you can enter some text into the editor area and test that you can then select some text that you entered and make it bold using the B button in the toolbar above the editor area.
• Risk associated with taking this patch: low
• Explanation of risk level: This extends a pre-existing compat hack and the conditions for this new activation (particular class name, particular name of an item in the global scope, and absence of the src attribute) are narrow enough for it to be implausible for the compat hack to activate when not intended.
• String changes made/needed: There is a new string for a console message in a .properties file.
• Is Android affected?: yes

Comment 14

[Phabricator Automation]

firefox-release Uplift Approval Request

• User impact if declined: The rich text editor component of GWT doesn't work in Firefox.

(Sorry about the large number of duplicate uplift requests for the dependency. The UI for this scenario is not great.)

• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing: On both https://demo.vaadin.com/sampler/#ui/data-input/text-input/rich-text-area and https://samples.gwtproject.org/samples/Showcase/Showcase.html#!CwRichText , test that you can enter some text into the editor area and test that you can then select some text that you entered and make it bold using the B button in the toolbar above the editor area.
• Risk associated with taking this patch: low
• Explanation of risk level: This extends a pre-existing compat hack and the conditions for this new activation (particular class name, particular name of an item in the global scope, and absence of the src attribute) are narrow enough for it to be implausible for the compat hack to activate when not intended.
• String changes made/needed: None. This patch for release removes the parts of the nightly and beta changes that involved a console message. That is, the compatibility hack in this version of the patch takes place without a use counter and without a console message.
• Is Android affected?: yes

Comment 15

[Henri Sivonen (:hsivonen)]

(In reply to Donal Meehan [:dmeehan] from comment #8)

Tracked for Fx148 release. To add to Comment 7, please also add a release uplift request

Added uplift requests. I requested uplifts for the dependency first, so it got duplicate requests. The UI for this scenario is hard to figure out. Sorry.

Comment 16

[Henri Sivonen (:hsivonen)]

(I built and manually tested the uplifts locally.)

Comment 17

[Henri Sivonen (:hsivonen)]

In case it's not OK to uplift the new string into beta, either, the patch here for the release branch would also apply to beta if applied instead of the one that I requested uplift for.

Comment 18

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/6de52d04ec7b
https://hg.mozilla.org/releases/mozilla-release/rev/15542f265e9e

Comment 19

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/7ecb95ba4d14
https://hg.mozilla.org/releases/mozilla-beta/rev/6ad658e8f97d

Comment 20

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Reproduced the issue with Firefox 150.0a1 (2026-03-04) on Windows 11 by following steps from comment 13.
The issue is verified fixed with Firefox 150.0a1 (2026-03-09), 149.0b7 (comment 19) and 148.0.2. The text can be successfully entered inside the test cases from comment 13 and formatted as bold, italic, or underlined.

Comment 21

[Henri Sivonen (:hsivonen)]

For future reference:

• Firefox 147 didn't show this issue, because sync about:blank was not yet there.
• Firefox 148.0.0 didn't work with the GWT RichTextArea, because sync about:blank was there but this compat hack was not.
• Firefox 148.0.2 has the compat hack without a message to the console in dev tools and without a use counter, and the compat hack requires building the GWT app with the default linker options that put GwtPotentialElementShim in the global scope.
• Firefox 149 and later look for __gwt_stylesLoaded in the global scope instead (bug 2022476), so the compat hack should work with any GWT linking alternatives. There is a message to the console in dev tools and a use counter.