TinyMCE editor doesn't load properly when initializing on Visual Tab (Firefox)

[metalandcoffee]

I've noticed that since updating to WordPress 5.6, TinyMCE editors within my custom metaboxes will sometimes fail to load/initialize when using the Firefox browser. This only happens when the editor is initializing on the Visual tab. If I switch to the Text tab and then reload the page, the editor initializing normally. Please see the attached video for a clear understanding of what the issue is (firefox-bug-issue.mov). This screen recording will show that when you first go to the post, the TinyMCE editor initializes properly. But if you refresh the page, then the editor isn't initialized at all. It doesn't always happen like this. Sometimes I'll go to a post edit page and it's not initialized from the start.

Theory:
I say that this "sometimes" happens because it's almost like the tinymce js resources are loading too slow or too fast. This isn't a browser caching issue either because if I hard refresh the page, it still depends on how fast the resources are loading as to whether or not the TinyMCE editors will be properly initialized or not.

I've confirmed that this was working fine on WordPress version 5.5.3.

Steps to reproduce:
I attached a file called "test-code.php" which will add a metabox with the TinyMCE editor to the 'post' post type.

1. Add test code to theme or plugin.
2. Open Firefox.
3. Migrate to post edit page.
4. See if you are able to click inside of the TinyMCE editor on the Visual tab.
5. Refresh the page and repeat.

[spikeuk1]

Looks likely to be related to Ticket #52111.

[desrosj]

@metalandcoffee I know that these are editors within custom metaboxes, but can you clarify whether the Classic Editor plugin is active? I'm not sure that would make a difference, but confirming the behavior with and without the plugin could help find the issue here.

Just to be sure, I double checked there were no TinyMCE updates available. 4.9.11 is the latest 4.x version and there are no 4.x ​bug fixes waiting to be released.

[metalandcoffee]

Hi @desrosj - The Classic Editor plugin was not installed when I did the initial testing for this ticket.

[spikeuk1]

There is some information on ​https://wordpress.org/support/topic/edit-post-page-broken-after-update-to-wp-5-6-2/#post-13878107 that may be relevant to this issue.

Spike

[whyisjake]

Bumping to 5.6.2

[desrosj]

5.6.2 RC is going to be packaged in a few hours. Since this one still requires some investigation and lacks a patch, I'm going to punt to Future Release.

[patkemper]

Replying to desrosj:

5.6.2 RC is going to be packaged in a few hours. Since this one still requires some investigation and lacks a patch, I'm going to punt to Future Release.

I really don't understand, why such problems are "punted to Future Releases". Updating jQuery caused severe issues and I don't see any progress on this.

Why is downgrading jQuery no option?

[herrvigg]

I'm recopying here what I wrote in other tickets. Not sure but this could explain the problem, asynchronous firing with jQuery3: ​https://github.com/jquery/jquery/issues/3194

With jQuery3, ready handlers fire asynchronously and may be fired after load... there's no guarantee so that can explain some "random" behaviors.

Long story short, the load trigger should never be set in the ready callback but outside. Ideally it should even be avoided when using ready.