WordPress.org

Make WordPress Core

Opened 5 months ago

Last modified 8 weeks ago

#52133 reopened defect (bug)

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

Reported by: metalandcoffee Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 5.6
Component: TinyMCE Keywords: needs-testing
Focuses: Cc:

Description

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.

Attachments (2)

firefox-bug-issue.mov (3.9 MB) - added by metalandcoffee 5 months ago.
test-code.php (1.3 KB) - added by metalandcoffee 5 months ago.

Change History (17)

#1 @johnbillion
5 months ago

  • Milestone changed from Awaiting Review to 5.6.1

#2 @spikeuk1
5 months ago

Looks likely to be related to Ticket #52111.

#3 @desrosj
4 months ago

  • Keywords needs-testing added

@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.

#4 @metalandcoffee
4 months ago

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

This ticket was mentioned in Slack in #core by metalandcoffee. View the logs.


4 months ago

This ticket was mentioned in Slack in #core by audrasjb. View the logs.


3 months ago

#8 @whyisjake
3 months ago

  • Milestone changed from 5.6.1 to 5.6.2

Bumping to 5.6.2

#9 follow-up: @desrosj
3 months ago

  • Milestone changed from 5.6.2 to Future Release

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.

#10 in reply to: ↑ 9 @patkemper
3 months ago

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?

#11 @herrvigg
2 months ago

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.

#12 follow-up: @patkemper
8 weeks ago

  • Resolution set to worksforme
  • Status changed from new to closed

A few clients confirmed, that this bug seems to be fixed due to latest WP-update.

#13 follow-up: @metalandcoffee
8 weeks ago

  • Resolution worksforme deleted
  • Status changed from closed to reopened

Hi @patkemper - I'm not sure why you closed this ticket. I'm glad that it's working for you but I just tested it with the exact same scenario that led me to open this ticket (on WordPress 5.7) and it is still an issue that should be kept open for the time being.

Last edited 8 weeks ago by metalandcoffee (previous) (diff)

#14 in reply to: ↑ 12 @spikeuk1
8 weeks ago

Replying to patkemper:

A few clients confirmed, that this bug seems to be fixed due to latest WP-update.

And my related ticket (https://core.trac.wordpress.org/ticket/52111) is still valid in 5.7, as it was in 5.6.2, 5.6.1, and 5.6.

Spike

#15 in reply to: ↑ 13 @patkemper
8 weeks ago

Replying to metalandcoffee:

Hi @patkemper - I'm not sure why you closed this ticket. I'm glad that it's working for you but I just tested it with the exact same scenario that led me to open this ticket (on WordPress 5.7) and it is still an issue that should be kept open for the time being.

I'm so sorry. Didn't mean to close it right away.
Anyway, my clients are still using 5.6.2, next week 5.7 will be rolled out. I will still monitor this issue.

Note: See TracTickets for help on using tickets.