Please check your browser console for any javascript errors

Hi, I checked, but there is no javascript errors in the browser console.
Also on Network tab of browser developer tools I don't see any request with 404 status.

Confirmed

There should be an older issue for this one (edit: #37297) but anyways I will try to explain what is happening, what is actually wrong in the Joomla codebase and the 3 possible ways to fix this. The default editor is rendered in the first tab of the article edit form. In that tab also ALL the modals are rendered (echoed from PHP if you prefer). The tab Fields that has the second instance of the editor has ONLY the buttons (bellow the none/codemirror). The problem (is not unique to this case, it also happens in the toolbar and other places where the modal could be under a hidden div/section/etc) is that the modal when it's being called will never appear because one of the parent elements has a display:none, it is hidden, so you only get the backdrop. Great stuff!

How to solve it? There are some nasty hacks and some nice ways (you pick your poison):

• Use JS to move the modal to the end of the document. This is hacky, it is complicated and prone to bugs and it's what Joomla is doing at the moment for the toolbar buttons that open a modal, ie:

  joomla-cms/build/media_source/com_contenthistory/js/admin-history-versions.es6.js

  Lines 6 to 11 in 06038e5

  	window.addEventListener('DOMContentLoaded', () => {
  	const versionsModal = document.getElementById('versionsModal');
  	if (versionsModal) {
  	document.body.appendChild(versionsModal);
  	}
  	});

• Resurrect my PR: #37330 which adds a simple mechanism to enqueue chinks of HTML that should be rendered at the end of the body. This is completely B/C, it requires minimal changes and it's clean, the dev decides where to render the modal.
• Cancel the Bootstrap Modal altogether, because it's (almost) 2023 and all browsers support the native DIALOG element. This, depending how it would be implemented, might have 0 to major B/C breaks.

Pick your poison...

I think I found a 4th one, please see #39287 :)

I think I found a 4th one, please see #39287 :)

@OctavianC that would work but also explodes the number of elements in a page (in other words it won't scale, so also tinyMCE is wrong in that case. Probably I'm the one to be blamed there)

I agree, but on the other hand, I don't think you'll stumble upon that many editor instances on a single page...

Hi, just to mention, there can be variable number of editors on a single page on article, when using custom fields.
You can have some fixed number of custom fields type Editor,
and also variable number of editors when using editors within Subform field with repeatable option.

Closing as having a pull request. Please test #39295 . Thanks in advance.

I have tested this, #39287 and #39295, and both works for me. Great job!