Make WordPress Core

Opened 6 months ago

Last modified 10 days ago

#57995 new defect (bug)

Popup flickering in Firefox

Reported by: robehr79's profile robehr79 Owned by:
Milestone: 6.4 Priority: normal
Severity: major Version: 6.0
Component: TinyMCE Keywords: needs-patch dev-feedback has-screenshots
Focuses: javascript, administration Cc:

Description (last modified by sabernhardt)

This bug is somehow related to #44911, however, 5 years after that, the bug appears in Firefox. I copy-paste here what I wrote in the forum (

  1. Begin editing a page in the block editor
  2. Insert a Classic block (TinyMCE)
  3. Mark some text
  4. Turn it into a link
  5. Enter a URL which is wider than the input field, e.g.
  6. Close the input field
  7. Reopen the input field
  8. Click on the pencil to edit it
  9. Expected behaviour: Turn it into the input field again. Actual behaviour: Starts flickering and is impossible to work with.

I found the relevant code in the file wp-include/js/tinymce/plugins/wordpress/plugin.js in line 1127 and following, stating:

					 * Showing a tooltip may trigger a resize event in Chromium browsers.
					 * That results in a flicketing inline menu; tooltips are shown on hovering over a button,
					 * which then hides the toolbar on resize, then it repeats as soon as the toolbar is shown again.
					if ( event.type === 'resize' || event.type === 'resizewindow' ) {

Funnily enough, there is a remark about this behaviour, but it concerns only Chromium. Firefox uses the event scroll. I tried appending it to the condition, and it really fixed the problem. However, I do not know if just appending || event.type === 'scroll' does not break other things. Actually, I think that the correct solution would be like this: The current condition is about resizing. There should be another condition which caches the previous scrolling position and bails out early if the scroll position did not change altough the event is fired.

This code is present at least since WordPress 6.0 and also in 6.1.1.

Attachments (1)

57995-replication-firefox.gif (814.0 KB) - added by rajinsharwar 8 weeks ago.

Download all attachments as: .zip

Change History (17)

#1 @sabernhardt
6 months ago

  • Description modified (diff)
  • Focuses javascript administration added
  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to 6.2.1

Hi and thanks for the report!

It flickered for me, too, in the editor's Classic block but not in the Classic Editor. I used Firefox 111.0.1 in Windows 10, and it still occurs with WordPress 6.2 RC4.

#2 @kelvinballoo
6 months ago

So I want to expand on this more.

I've reproduced the issue with the classic block on a few browsers on PHP 7.4 , WordPress 6.1.1:

  1. Create post
  2. Add 'Classic' block (did not have tinyMCE)
  3. Add text under classic block and assign URL to it.

Here are my observations:
-> Safari (Version 16.3 (17614., 17614)) - Works perfect.

-> Chrome (Version 111.0.5563.146 (Official Build) (x86_64)) - There are some flickers that happened when I tried to select the inserted URL (URL is longer than the input field) but it's still workable. The flicker should be fixed though.

-> Firefox (111.0.1 (64 bit))- This is the most problematic.

  • Not only the flicker is much more, you hardly can do anything when you have a long URL. Sometimes the URL popup won't even appear.
  • Short URLs are fine but sometimes the link popup won't disappear after clicking elsewhere on the page.
  • If you have a scenario with 2 links, one which is a short URL which was working fine...and if you insert another long URL somewhere else on the page, this will affect the experience for the short URL too.

#3 @costdev
6 months ago

  • Keywords dev-feedback added
  • Version changed from 6.1.1 to 6.0

Pinging @azaozz as TinyMCE component maintainer to take a look if available. Note the support thread mentioned in this ticket's summary also.

A couple of questions for consideration:

  • Is a fix needed here, or in Gutenberg?
  • This issue has existed in 6.0, 6.1 and now 6.2. Should a fix be committed to trunk only, or should it be backported to the 6.2 and possibly the 6.1 branches?

#4 @parrishh
6 months ago

#58072 was marked as a duplicate.

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

5 months ago

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

5 months ago

#7 @audrasjb
5 months ago

  • Milestone changed from 6.2.1 to 6.2.2

@costdev it has to be committed to trunk and backported to branch 6.2 only :)

As per today's bug scrub, let's move this ticket to 6.2.2.
If a patch is added to the ticket before tomorrow 15:00 UTC and WP 6.2.1 RC1, feel free to move it back to milestone 6.2.1!

#8 @robehr79
4 months ago

Sorry for coming up this way by simply putting the patch verbatim here, but I think that this is the fix to the flickering, as patch generated with Git:

--- a/wp-includes/js/tinymce/plugins/wordpress/plugin.js
+++ b/wp-includes/js/tinymce/plugins/wordpress/plugin.js
@@ -790,12 +790,14 @@ tinymce.PluginManager.add( 'wordpress', function( editor ) {
                        container = editor.getContainer(),
+                       editorContainer = document.querySelector(".interface-navigable-region.interface-interface-skeleton__content"),
                        wpAdminbar = document.getElementById( 'wpadminbar' ),
                        mceIframe = document.getElementById( + '_ifr' ),
-                       cachedWinSize;
+                       cachedWinSize,
+                       cachedScrollPos;
                        if ( container ) {
                                mceToolbar = tinymce.$( '.mce-toolbar-grp', container )[0];
@@ -1154,6 +1156,19 @@ tinymce.PluginManager.add( 'wordpress', function( editor ) {
+                                       if ( event.type === "scroll" || event.type === "scrollwindow" ) {
+                                               if ( cachedScrollPos ) {
+                                                       if ( editorContainer.scrollLeft === cachedScrollPos.X && editorContainer.scrollTop === cachedScrollPos.Y ) return;
+                                               } else {
+                                                       cachedScrollPos = {
+                                                               X: editorContainer.scrollLeft,
+                                                               Y: editorContainer.scrollTop,
+                                                       };
+                                                       return;
+                                               }
+                                       }
                                        clearTimeout( timeout );
                                        timeout = setTimeout( function() {
@@ -1165,6 +1180,7 @@ tinymce.PluginManager.add( 'wordpress', function( editor ) {
                                        activeToolbar.scrolling = true;
+                                       cachedScrollPos = null;

Feel free to improve it accordingly. Sadly enough, this fixes the flickering but there is another issue: The toolbar does not close reliably when it loses the focus, neither in Firefox nor in Chrome, neither with nor without this fix.

Sorry, I won't have time to investigate deeper. I hope my contribution helps.

Kind regards,

Last edited 4 months ago by robehr79 (previous) (diff)

#9 @desrosj
4 months ago

  • Milestone changed from 6.2.2 to 6.2.3

Moving this to 6.2.3.

#10 @lgladdy
4 months ago

This happens in Chrome too when a WYSIWYG is being displayed in a meta box with a position set to side

Version 0, edited 4 months ago by lgladdy (next)

#11 @mrinal013
3 months ago

  • Keywords needs-testing added

In WordPress Core, the version of TinyMCE is 4.9.11
The latest version of TinyMCE is 5.10.7 - December 6, 2022
Is this issue happen for updating?

#12 @rajinsharwar
8 weeks ago

  • Keywords has-screenshots added; needs-testing removed

Hey all, the issue does seem to be still replicable in 6.2.2 but is solved in 6.3 RC@ because of the new popup system while using classic blocks.

#13 @SergeyBiryukov
6 weeks ago

  • Milestone changed from 6.2.3 to 6.4

Moving to 6.4 for now, as there are no plans for 6.2.3 at this time, and this does not appear to be a regression in 6.3.

If this is indeed fixed in 6.3 as noted in comment:12, would be great to track down the exact commit.

#14 @robertehrenleitnerplus
6 weeks ago

It's still not fixed. Neither do I see my suggested fix, nor in any other way.

#15 @oglekler
4 weeks ago

comment:8 has a proposed fix in plain text. We need to make a patch file from it, and it will be clear if it will solve the issue or something else should be done.

#16 @robertehrenleitnerplus
10 days ago

Whoops, I just noticed that I have two accounts. @robehr79 and @robertehrenleitnerplus is both me.

Note: See TracTickets for help on using tickets.