2020668 - Since Firefox 148, ZE rich text editor in old version of Zoho's ManageEngine's ServiceDesk Plus remains blank

Status: RESOLVED FIXED

(Core :: DOM: Navigation, defect)

Description

[Terry]

Attachment: Capture.PNG

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

Steps to reproduce:

Hello

We use ManageEngine's ServiceDesk plus and all has been fine until Firefox 148 update was installed (on a number of our office PCs).

The body of a request where we type details of a case or insert images now will not display anything. The data fields are fine, it is just the description box which appears to be iframe. Other browsers still work, but we prefer FF.

n.b. this is on an internal IP address, so I cannot give you a URL.

Thanks in advance - Terry

Actual results:

The window for the description shows as blank and we cannot enter anything in to it.

Expected results:

The window for the description normally opens and we can add text or images to the support case.

Comment 1

[Gregory Pappas [:gregp]]

Guessing bug 543435, but it'd be very helpful if you used a tool called mozregression to find out which specific code change caused the breakage, since we don't have access to your application.

Comment 2

[Vincent Hilla [:vhilla]]

Hi, thanks for the report! It's difficult to diagnose this without access to the page.

What is the HTML markup of that iframe? You can inspect the element in devtools, right click, copy, select outer html and paste it here? I wonder if that description box is a fork of CKEditor and related to bug 2002481.

Please also try to dispatch a load event on that iframe. E.g. execute in the console document.querySelectorAll("iframe").forEach(ifr => ifr.dispatchEvent(new Event("load"))).

Comment 3

[BugBot [:suhaib / :marco]]

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

Comment 4

[Terry]

(In reply to Gregory Pappas [:gregp] from comment #1)

Guessing bug 543435, but it'd be very helpful if you used a tool called mozregression to find out which specific code change caused the breakage, since we don't have access to your application.

(In reply to Vincent Hilla [:vhilla] from comment #2)

Hi, thanks for the report! It's difficult to diagnose this without access to the page.

What is the HTML markup of that iframe? You can inspect the element in devtools, right click, copy, select outer html and paste it here? I wonder if that description box is a fork of CKEditor and related to bug 2002481.

Please also try to dispatch a load event on that iframe. E.g. execute in the console document.querySelectorAll("iframe").forEach(ifr => ifr.dispatchEvent(new Event("load"))).

We will try what you suggest and can possibly let you see if happening if we can find a way to authenticate a remote session with you?
Thanks for the assistance, but finding the email traffic/reports a bit overwhelming, not sure what to take notice of/reply to. Terry

Comment 5

[Henri Sivonen (:hsivonen) (away from Bugzilla until 2026-08-27)]

n.b. this is on an internal IP address, so I cannot give you a URL.

It's likely that there is an identifiable editor component for the description field. If you use the DOM inspector in the developer tools of Firefox 147 or Chrome to inspect what the editor field is like, do you see an iframe there? Does the iframe have a class attribute? If it does, what's the value?

Comment 6

[Henri Sivonen (:hsivonen) (away from Bugzilla until 2026-08-27)]

There's a demo of the hosted version of the product at https://demo.servicedeskplus.com/ , and its editor works (and has a newer-looking theme than the screenshot).

The editor seems to bootstrap from srcdoc instead of about:blank, and that could well be a way to deliberately avoid about:blank issues, so it seems plausible that an older version might have bootstrapped from about:blank.

I don't find signs of the editor in the current version demo being a fork of CKEditor 4. The editor in the current version uses zei as a class value prefix, and it looks a lot like it could be called Zoho Editor.

I fail to see zoho.com providing an editor library named like that, though.

Reporter, is your organization running a very old copy of ServiceDesk by any chance?

I'm marking this S3 rather than S2 due to it appearing that the latest version of ServiceDesk Plus works based on the demo version.

Comment 7

[Jānis Elmeris]

It seems we had a similar problem – using some kind of CKEditor 4 in our internal applications.

The fix introduced in bug 2002481 somehow didn't help (it seems the fix tries to detect CKEditor and apply a workaround for it, but our CKEditor 4 was either an unexpected version (it's not the latest 4, and it's not minified) or in some way modified such that the detection didn't work).

Not having found these bugs on this tracker, I did some debugging by myself until I reached a solution by swapping commands for attaching event and adding the iframe to DOM (see line iframe.on( 'load', onLoad ); in wysiwygarea/plugin.js).

However, I would like to note that when the problem occurred, it was not clear how soon or if we can fix it at all (as there were no error messages anywhere, the application just did not work). The quick temporary workaround was found to switch to Google Chrome instead. And even though we've fixed our CKeditor code now, and the users can again work with the latest Firefox after a day's interruption, a yet another push towards Google Chrome has happened, and at least some of the users will probably continue with Chrome instead now.

Comment 8

[Tatu Lund]

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

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.

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 9

[Henri Sivonen (:hsivonen) (away from Bugzilla until 2026-08-27)]

(In reply to Jānis Elmeris from comment #7)

The fix introduced in bug 2002481 somehow didn't help (it seems the fix tries to detect CKEditor and apply a workaround for it, but our CKEditor 4 was either an unexpected version (it's not the latest 4, and it's not minified) or in some way modified such that the detection didn't work).

What's the class name of the editor iframe in your case? In the JavaScript file for your instance of CKEditor, do you see an assigment of a function to window.CKEDITOR? If so, do you see a JavaScript object with fields timestamp, version, and revision inside the function? What's the value for version?

a yet another push towards Google Chrome has happened, and at least some of the users will probably continue with Chrome instead now.

This is a general problem with increasing compatibility with Chrome: If we don't, that's a problem. If we do (as we did here), that's a problem, too, with scripts that sniffed browser name and expected browser-specific behavior. Many problems are caught by users running Nightly and Beta. Unfortunately your instance of CKEDITOR wasn't caught that way.

Comment 10

[Henri Sivonen (:hsivonen) (away from Bugzilla until 2026-08-27)]

(In reply to Tatu Lund from comment #8)

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

There is live demo here for you to check:

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

Based on https://samples.gwtproject.org/samples/Showcase/Showcase.html#!CwRichText , it looks like the latest version of GWT works, which would explain how this went unnoticed during Nightly and Beta.

It seems that the GWT widget has a distinguishing class (gwt-RichTextArea), so we might be able to deploy a workaround similar to the CKEditor 4 workaround. However, it's unclear from the minified JS whether the class is set before the iframe is inserted. Also, since the current version appears to work, it would be prudent to scope a workaround to target old version that don't work.

Tatu, do you happen to know if the old broken GWT widget and the new working GWT widget put some obvious distinguisher (e.g. version number) in the global JavaScript scope?

(Like CKEditor 4, the old GWT widget appears to be doing UA sniffing, and changing the UA string to the Chrome UA string makes the editor work.)

Comment 11

[Henri Sivonen (:hsivonen) (away from Bugzilla until 2026-08-27)]

GWT seems to be tolerant of multiple load events on the iframe, so perhaps we could get away with firing an extra load event on iframe with the class gwt-RichTextArea without trying to distinguish between working and broken version:
https://github.com/gwtproject/gwt/blob/4b6a646faf0e9ce579658d78b6acf9fe5c840379/user/src/com/google/gwt/user/client/ui/impl/RichTextAreaImplMozilla.java#L46

Comment 12

[Tatu Lund]

Based on https://samples.gwtproject.org/samples/Showcase/Showcase.html#!CwRichText , it looks like the latest version of GWT works, which would explain how this went unnoticed during Nightly and Beta.

To me this page is even more broken than our Vaadin demo, the caret is not appearing in the edit area at all.

I need to re-check, but by brief glance RichTextArea implementation has been unchanged between GWT 2.8.2 that is used in the demo app I linked and the actual version 2.11.0 we use nowadays in latest Vaadin 8 release. Only things are see there is some code style fix adding suppress warnings and removal of IE specific classes.

Comment 13

[Henri Sivonen (:hsivonen) (away from Bugzilla until 2026-08-27)]

(In reply to Tatu Lund from comment #12)

Based on https://samples.gwtproject.org/samples/Showcase/Showcase.html#!CwRichText , it looks like the latest version of GWT works, which would explain how this went unnoticed during Nightly and Beta.

To me this page is even more broken than our Vaadin demo, the caret is not appearing in the edit area at all.

Indeed, this was a testing failure at my end. I forgot to remove the Chrome UA override before testing. So it does work with the UA string spoofed to Chrome.

Comment 14

[Tatu Lund]

Indeed, this was a testing failure at my end. I forgot to remove the Chrome UA override before testing. So it does work with the UA string spoofed to Chrome.

So in that case workarounds for some older Firefox related behaviors in RichTextAreaImplMozilla.java are no longer necessary with modern Firefox if it works without those.

Comment 15

[Jānis Elmeris]

(In reply to Henri Sivonen (:hsivonen) from comment #9)

(In reply to Jānis Elmeris from comment #7)

The fix introduced in bug 2002481 somehow didn't help (it seems the fix tries to detect CKEditor and apply a workaround for it, but our CKEditor 4 was either an unexpected version (it's not the latest 4, and it's not minified) or in some way modified such that the detection didn't work).

What's the class name of the editor iframe in your case? In the JavaScript file for your instance of CKEditor, do you see an assigment of a function to window.CKEDITOR? If so, do you see a JavaScript object with fields timestamp, version, and revision inside the function? What's the value for version?

Classes "cke_wysiwyg_frame" and "cke_reset" are added to the iframe:

var iframe = CKEDITOR.dom.element.createFromHtml( '<iframe src="' + src + '" frameBorder="0"></iframe>' );
iframe.setStyles( { width: '100%', height: '100%' } );
iframe.addClass( 'cke_wysiwyg_frame' ).addClass( 'cke_reset' );

The version's value is %VERSION%, and the same value is output in console for CKEDITOR.version (so I guess the editor has not been integrated quite properly), it seems to match this file: https://github.com/ckeditor/ckeditor4/blob/4.4.8/core/ckeditor_base.js

Comment 16

[Henri Sivonen (:hsivonen) (away from Bugzilla until 2026-08-27)]

(In reply to Jānis Elmeris from comment #15)

The version's value is %VERSION%, and the same value is output in console for CKEDITOR.version (so I guess the editor has not been integrated quite properly), it seems to match this file: https://github.com/ckeditor/ckeditor4/blob/4.4.8/core/ckeditor_base.js

Thanks.

As for sniffing GWTness beyond a class name, it seems GWT puts window.__gwt_activeModules in the global scope, but it doesn't help with deactivating a hack for a future version of GWT.

Comment 17

[Henri Sivonen (:hsivonen) (away from Bugzilla until 2026-08-27)]

Let's use bug 2020927 for further GWT-specific tracking of this.

Comment 18

[Henri Sivonen (:hsivonen) (away from Bugzilla until 2026-08-27)]

(In reply to Jānis Elmeris from comment #15)

The version's value is %VERSION%, and the same value is output in console for CKEDITOR.version (so I guess the editor has not been integrated quite properly), it seems to match this file: https://github.com/ckeditor/ckeditor4/blob/4.4.8/core/ckeditor_base.js

Let's use bug 2020953 for this.

Comment 19

[Henri Sivonen (:hsivonen) (away from Bugzilla until 2026-08-27)]

(In reply to Henri Sivonen (:hsivonen) from comment #6)

I don't find signs of the editor in the current version demo being a fork of CKEditor 4. The editor in the current version uses zei as a class value prefix, and it looks a lot like it could be called Zoho Editor.

I fail to see zoho.com providing an editor library named like that, though.

Reporter, is your organization running a very old copy of ServiceDesk by any chance?

Reporter, can you confirm that your organization is using an old copy of ServiceDesk? Can you identify which version?

Is the editor using an identifiable editor library that you could find a public live demo of?

Comment 20

[Terry]

Hi,

Yes it IS an old version of ManageEngine'ss ServiceDeskPlus

v9.4 build 9410.

We purchased an outright licence and it does what we want (solidly), and we don't need any of the extra features or the maintenance charges ...

The feature that is failing in Firefox appears to work fine in Chrome and Edge (current versions) but we prefer to use Firefox where we can.

I have been trying to keep up with the traffic on bugzilla, but if we have missed a request for more info, please forward your request in a DM if bugzilla supports it?

Thanks - Terry

Comment 21

[Henri Sivonen (:hsivonen) (away from Bugzilla until 2026-08-27)]

Bugzilla doesn't have DMs, but I'll also send you direct email.

If you look at the editor in Firefox's Developer Tools, is there a class name on the iframe? Is there a JavaScript file for the editor whose name would identify a third-party component?

Comment 22

[Henri Sivonen (:hsivonen) (away from Bugzilla until 2026-08-27)]

Attachment: Bug 2020668 - Extend the CKEditor hack to ZE (preffed off).

Comment 23

[Henri Sivonen (:hsivonen) (away from Bugzilla until 2026-08-27)]

Shippable-config test builds coming up in:
https://treeherder.mozilla.org/jobs?repo=try&landoCommitID=184365

Comment 24

[BugBot [:suhaib / :marco]]

The bug is marked as tracked for firefox149 (beta). However, the bug still has low severity.

:hsinyi, could you please increase the severity for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 25

[Vincent Hilla [:vhilla]]

If other users experience issues with ManageEngine's ServiceDesk's editor and find this issue, please let us know.

Specifically, we are interested in what other versions are affected, what variables the editor defines on the global, and whether a version can be made available to us for testing.

Comment 26

[Henri Sivonen (:hsivonen) (away from Bugzilla until 2026-08-27)]

For release management: I'm waiting for additional information to proceed.

Comment 27

[Henri Sivonen (:hsivonen) (away from Bugzilla until 2026-08-27)]

The patch that is queued for landing is preffed off for experimentation. It's not enough to consider this fixed.

Comment 28

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/b314dceddaae
https://hg.mozilla.org/integration/autoland/rev/c6201df0e96e
Extend the CKEditor hack to ZE (preffed off). r=vhilla,emilio

Comment 29

[Henri Sivonen (:hsivonen) (away from Bugzilla until 2026-08-27)]

(In reply to BugBot [:suhaib / :marco/ :calixte] from comment #24)

The bug is marked as tracked for firefox149 (beta). However, the bug still has low severity.

I deliberately triaged this as S3 while triaging bug 2020927 as S2: In the case of GWT, the latest version is affected. In the case of ZE, the latest version is not affected but version from about 7 years ago is affected. We don't know if old ZE has wide impact.

Furthermore, with GWT the editor is available to us for experimentation. In the case of ZE, old version that is broken isn't available to us for experimentation, so as a practical matter, we can't really proceed as quickly as we could with GWT.

Comment 30

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

(In reply to Henri Sivonen (:hsivonen) from comment #29)

(In reply to BugBot [:suhaib / :marco/ :calixte] from comment #24)

The bug is marked as tracked for firefox149 (beta). However, the bug still has low severity.

I deliberately triaged this as S3 while triaging bug 2020927 as S2: In the case of GWT, the latest version is affected. In the case of ZE, the latest version is not affected but version from about 7 years ago is affected. We don't know if old ZE has wide impact.

Furthermore, with GWT the editor is available to us for experimentation. In the case of ZE, old version that is broken isn't available to us for experimentation, so as a practical matter, we can't really proceed as quickly as we could with GWT.

I'd second the severity reasoning in the comment above, while it's also worthwhile tracking this new regression and if we have a fix, it's worthwhile considering an uplift.

Comment 31

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/cb2934aa4446
https://hg.mozilla.org/integration/autoland/rev/21af15965e04
Revert "Bug 2020668 - Extend the CKEditor hack to ZE (preffed off). r=vhilla,emilio" for causing assertion failures on nsGlobalWindowInner.cpp.

Comment 32

[Iulian Moraru]

Revert for causing assertion failures on nsGlobalWindowInner.cpp.

• Push with failures

• Failure log

• Backout link

Comment 33

[Henri Sivonen (:hsivonen) (away from Bugzilla until 2026-08-27)]

(In reply to Iulian Moraru from comment #32)

Revert for causing assertion failures on nsGlobalWindowInner.cpp.

• Push with failures

• Failure log

• Backout link

Landing re-queued with the assertion moved after the iframeness check, since we can start running the function with a frame element.

Comment 34

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/fa367e1d5466
https://hg.mozilla.org/integration/autoland/rev/63a3d50e6360
Extend the CKEditor hack to ZE (preffed off). r=vhilla,emilio

Comment 35

[Silaghi Andreea]

https://hg.mozilla.org/mozilla-central/rev/63a3d50e6360

Comment 36

[Henri Sivonen (:hsivonen) (away from Bugzilla until 2026-08-27)]

Attachment: Bug 2020668 addendum - Check for ZE_Init instead of ZComponents and enable the ZE compat hack by default.

Comment 37

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/54588fc7de3e
https://hg.mozilla.org/integration/autoland/rev/994d798e2f96
addendum - Check for ZE_Init instead of ZComponents and enable the ZE compat hack by default. r=emilio

Comment 38

[rperta]

https://hg.mozilla.org/mozilla-central/rev/994d798e2f96

Comment 39

[BugBot [:suhaib / :marco]]

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 40

[Henri Sivonen (:hsivonen) (away from Bugzilla until 2026-08-27)]

(In reply to BugBot [:suhaib / :marco/ :calixte] from comment #39)

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

The fix hasn't been verified in Nightly, yet. If I hear back that the latest Nightly works, I'll request uplift.

Comment 41

[Henri Sivonen (:hsivonen) (away from Bugzilla until 2026-08-27)]

Attachment: Bug 2020668 - Extend the CKEditor hack to ZE (preffed off).

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

Comment 42

[Henri Sivonen (:hsivonen) (away from Bugzilla until 2026-08-27)]

Attachment: Bug 2020668 addendum - Check for ZE_Init instead of ZComponents and enable the ZE compat hack by default.

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

Comment 43

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined/Reason for urgency: An old version of the ZE rich text editor used at least in enterprise software from Zoho does not work in Firefox. It's unknown how widely users experience this problem. The problem occurs with on-prem-hosted behind firewall/login old instances of the software.
• Code covered by automated testing?: yes
• Fix verified in Nightly?: yes
• Needs manual QE testing?: no
• Steps to reproduce for manual QE testing: We don't have access to the old version of ZE to allow manual verification in that sense. However, to verify that this doesn't break the current version of ZE:

1. go to https://demo.servicedeskplus.com/
2. click "Requester Login"
3. Click the red button that says something to the effect of "I have a problem" (it shows it in Finnish for me)
4. Click "Email"
5. Click "Mail Fetchin"
6. Type something in the largest editor field and check that you can make selected text bold using the toolbar button.

• Risk associated with taking this patch: low
• Explanation of risk level: The risk is low, because the compat hack requires a particular iframe class name and an additional distinguisher in the global scope to exist, and we have visibility into the latest version and can manually test that the hack does not a activate on the latest version that doesn't need the compat hack.
• String changes made/needed?: There is one console message string.
• Is Android affected?: yes

Comment 44

[Henri Sivonen (:hsivonen) (away from Bugzilla until 2026-08-27)]

Attachment: Bug 2020668 - Extend the CKEditor hack to ZE (uplift without console message).

Original Revision: https://phabricator.services.mozilla.com/D286262
Original Revision: https://phabricator.services.mozilla.com/D288077

Comment 45

[Phabricator Automation]

firefox-release Uplift Approval Request

• User impact if declined/Reason for urgency: An old version of the ZE rich text editor used at least in enterprise software from Zoho does not work in Firefox. It's unknown how widely users experience this problem. The problem occurs with on-prem-hosted behind firewall/login old instances of the software.
• Code covered by automated testing?: yes
• Fix verified in Nightly?: yes
• Needs manual QE testing?: no
• Steps to reproduce for manual QE testing: We don't have access to the old version of ZE to allow manual verification in that sense. However, to verify that this doesn't break the current version of ZE:

1. go to https://demo.servicedeskplus.com/
2. click "Requester Login"
3. Click the red button that says something to the effect of "I have a problem" (it shows it in Finnish for me)
4. Click "Email"
5. Click "Mail Fetchin"
6. Type something in the largest editor field and check that you can make selected text bold using the toolbar button.

• Risk associated with taking this patch: low
• Explanation of risk level: The risk is low, because the compat hack requires a particular iframe class name and an additional distinguisher in the global scope to exist, and we have visibility into the latest version and can manually test that the hack does not a activate on the latest version that doesn't need the compat hack.
• String changes made/needed?: None, this squashed patch omits the console message (and the use counter).
• Is Android affected?: yes

Comment 46

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/c7fa3c91990b
https://hg.mozilla.org/releases/mozilla-release/rev/b20f603334b8

Comment 47

[Adina Petridean QA [:apetridean]]

From Android QA testing, the functionality works correctly on the latest Nightly (150.0a1 from 18/03), Fenix 149.0b10, and RC 149.0. Testing was performed on Pixel 10 (Android 16) and Moto G72 (Android 13) devices using the steps from comment 45, and everything behaves as expected.

Comment 48

[Henri Sivonen (:hsivonen) (away from Bugzilla until 2026-08-27)]

For future reference for figuring out which release had what:

• Firefox 147 did not have the issue: sync about:blank was not there.
• Firefox 148 didn't work with old ZE: sync about:blank was there but the fix from this bug was not.
• Firefox 149 has the fix without a console message in dev tools and without the use counter.
• Firefox 150 has the fix with a console message in dev tools and with a use counter.

In all cases, the latest ZE doesn't have a problem.