WYSIWYG Jira Editor Breaks In Nightly
Categories
(Core :: DOM: Editor, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr140 | --- | unaffected |
| firefox145 | --- | unaffected |
| firefox146 | --- | unaffected |
| firefox147 | --- | fixed |
People
(Reporter: contact, Assigned: vhilla)
References
(Regression)
Details
(Keywords: regression)
Attachments
(4 files)
Screenshot 2025-12-03 at 9.18.16 AM.png
Steps to reproduce:
Firefox nightly 147.0a1 (2025-12-02) (aarch64)
Apple M2 Pro Sequoia 15.7.1
I really tried to create a minimal reproduction which didn't involve having access to a Jira LTS versioned server. But I literally cannot get this bug to happen unless it's on Jira. I will keep trying, open to any ideas.
- View an issue in Jira 10.3.3
- Click on the description area to try and edit the contents
Actual results:
Description area is replaced by a white box. When inspected it is an iframe with only an empty body and empty head element. The src is blank.
I did notice that in Firefox stable (144.0) the iframe's readyState was "uninitialized" after an iframe is added via js. But in nightly it is "complete". Maybe that's preventing content from loading correctly?
Expected results:
The description area gets replaced by a WYSIWYG editor which you can click in and type. This lives in an iframe with src being blank.
|
||
Comment 1•1 month ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: Editor' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Updated•1 month ago
|
I will note. This is a new issue. I remember it starting ~Thursday of last week after I updated. But I don't always get the chance to update every day.
|
Assignee | |
Comment 3•1 month ago
|
||
Hi, thanks for the report. This looks like bug 2002481 but that is fixed in my nightly 147.0a1 (2025-12-02).
Reporter, can you tell us what classes the iframe has, especially whether it has cke_wysiwyg_frame?
If so, can you report the value of the CKEDITOR.version gobal and iframe.src?
|
|
Assignee | |
Comment 4•1 month ago
|
||
( Thursday last week strongly indicates it's a regression from bug 543435 )
|
||
Comment 5•1 month ago
|
||
Marking as regressed by bug 543435 in order not to lose track of this. We can undo this if it turns out not to be true.
Okay "Nightly is up to date" on Dec 3, 2025 at 9:14 AM Eastern.
@Vincent The iframe has the classes: cke_wysiwyg_frame and cke_reset. The iframe's src attribute is set to an empty string ("").
Here is the full HTML of the iframe:
<iframe src="" frameborder="0" style="width: 100%; height: 100%;" class="cke_wysiwyg_frame cke_reset" title="Rich Text Editor, comment_AyauHXPVYa25IgSm" aria-describedby="cke_436" tabindex="0" allowtransparency="true">
#document
<html>
<head></head>
<body></body>
</html>
</iframe>
The CKEDITOR field was not defined. But JEDITOR was (going to assume it's a Jira wrapper of CKEditor). The jeditor.version was "4.15.0".
I looked at my browsing history in Firefox stable, which I only started using after the bug occured, and it looks like I ran into the bug first on December 1, 2025.
Attached are some screenshots of what the broken iframe looks like in nightly (a white box), what it looks like in Firefox stable (WYSIWYG editor), and also the CSS of those two classes I mentioned above.
|
Reporter | |
Comment 10•1 month ago
|
||
I should also mention the console output on Firefox nightly and Firefox stable is literally identical. No errors which showed up on Firefox nightly did not show up on Firefox stable.
|
|
Assignee | |
Comment 11•1 month ago
|
||
Thanks, I think this is exactly what we need to know.
In the meantime, you can work around this by spoofing your user agent as Chrome or calling dispatchEvent(new Event("load")) on the iframe.
|
||
Comment 12•1 month ago
|
||
Yeah it seems the workaround for bug 2002481 doesn't work because they are using JEDITOR rather than CKEDITOR in the global.
I guess potential fixes would be:
- Add
JEDITORto our ckeditor check. - Remove the JSValue check.
Either seems fine to me...
|
|
Assignee | |
Comment 13•1 month ago
|
||
|
||
Updated•1 month ago
|
|
|
Reporter | |
Comment 14•1 month ago
|
||
(In reply to Vincent Hilla [:vhilla] from comment #11)
In the meantime, you can work around this by spoofing your user agent as Chrome or calling
dispatchEvent(new Event("load"))on the iframe.
That works!
|
|
||
Comment 15•1 month ago
|
||
Set release status flags based on info from the regressing bug 543435
|
|
Reporter | |
Comment 16•1 month ago
|
||
(In reply to kiln8350 from comment #14)
(In reply to Vincent Hilla [:vhilla] from comment #11)
In the meantime, you can work around this by spoofing your user agent as Chrome or calling
dispatchEvent(new Event("load"))on the iframe.That works!
Sorry. Ambiguous there. The event dispatch thing works.
|
||
Comment 17•1 month ago
|
||
|
||
Comment 18•1 month ago
|
||
| bugherder | ||
|
|
Reporter | |
Comment 19•1 month ago
|
||
Fix confirmed on Dec 4, 2025 at 9:19 AM Eastern in 147.0a1 (2025-12-04) (aarch64)! Thank you very much for the speedy fix!
|
||
Updated•1 month ago
|
Description
•