Incorrect height of the WP editor, when loaded in a hidden layer

[nnikolov]

Using the wp_editor() function I am showing the editor inside a DIV tag that is hidden with display:none. Then I show the DIV with JavaScript to display:block. In WordPress 5.0 RC2 the height of the editor is incorrect.

This is the plugin I made to test this:

<?php
/*
Plugin Name: Test WP Editor
Description: Test WP Editor
Author: Nikolay Nikolov
Version: 1.0.0
*/

add_action( 'admin_menu', 'my_test_admin_menu' );

function my_test_admin_menu() {
    add_menu_page(
        'Test WP Editor',
        'Test WP Editor',
        'manage_options',
        'my-test-page',
        'my_test_page'
    );
}

function my_test_page() {
    ?>
    <div class="wrap">
        <br><br>
        <script type="text/javascript">
        function my_func() {
            document.getElementById('my-div').style.display='block';
        }
        </script>
        <a href="javascript:my_func()">SHOW IT</a>
        <br><br>
        <div id="my-div" style="display: none;">
        <?php
        $text = "<p>ddg fdgfd grgdfvg fdgfdg fdgfdgfdgddg fdgfd grgdfvg fdgfdg fdgfdgfdgddg fdgfd grgdfvg fdgfdg fdgfdgfdgddg fdgfd grgdfvg fdgfdg fdgfdgfdg</p>"
            . "<p>ddg fdgfd grgdfvg fdgfdg fdgfdgfdgddg fdgfd grgdfvg fdgfdg fdgfdgfdgddg fdgfd grgdfvg fdgfdg fdgfdgfdgddg fdgfd grgdfvg fdgfdg fdgfdgfdg</p>"
            . "<p>ddg fdgfd grgdfvg fdgfdg fdgfdgfdgddg fdgfd grgdfvg fdgfdg fdgfdgfdgddg fdgfd grgdfvg fdgfdg fdgfdgfdgddg fdgfd grgdfvg fdgfdg fdgfdgfdg</p>"
            . "<p>ddg fdgfd grgdfvg fdgfdg fdgfdgfdgddg fdgfd grgdfvg fdgfdg fdgfdgfdgddg fdgfd grgdfvg fdgfdg fdgfdgfdgddg fdgfd grgdfvg fdgfdg fdgfdgfdg</p>";
        wp_editor(
            $text,
            'editor-name',
            array(
                'editor_height' => 300,
            )
        );
        ?>
        </div>
    </div>
    <?php
}

Just upload and activate the plugin, go to the created admin page, and click the link there. See the pictures below to see the problem.

[jorbin]

Due to the impending release of WordPress 5.0.0, I'm putting this in the 5.0.1 milestone. It's going to need a patch fairly soon though. @pento if you think this should go in 5.0.0, I wouldn't object.

[audrasjb]

Hi,

5.0.3 is going to be released in a couple of weeks. We are currently sorting the remaining tickets in the milestone. It doesn't appear that ticket can be quickly processed (still needs a patch). Let's address it in 5.1 which is coming in February. Feel free to change/ask to change the milestone if you think the issue can be quickly resolved.

[nnikolov]

Hi guys.
I don't understand why all my tickets get pushed into the future and never get fixed. It seems that setting a milestone means nothing since it just gets changed when it gets close. Even on the ticket that I said exactly how to fix it, basically change one word, after 22 months, it is still not fixed. So far the idea of reporting WP bugs has produced zero results from my experience.

[audrasjb]

Hi @nnikolov

I totally understand your concern. However, to be fixed a ticket needs a patch. And to get a patch, it needs the work of a contributor. And that needs contributors interested by the issue, or reproducing it on their side.

There is some different ways to see that fixed:

• wait for an interested contributor to handle the work on that patch
• try to submit a patch by yourself so the ticket can move forward

Also, I'd recommend you to attend new contributors meetings and/or bug scrub to ask people directly about your tickets. That can helps a lot too.

I really hope you'll see your ticket moving forward soon.

So far the idea of reporting WP bugs has produced zero results from my experience.

There are dozens and dozens of reported bugs that are going to be addressed in the next minor release 5.0.3. These issues simply met some interested contributors. Hopefully that will happen to your ticket too.

[nnikolov]

@audrasjb

Thank you for your response. Isn't there some kind of order in which bugs are fixed relative to the order that they come in? It looks like bugs can be left behind forever if nobody is interested in a bug or even knows about it.

Maybe this is partially because we have to rely on contributors and not employees. But at least the system should provide some incentive to work on older bugs, and this should increase the more time a bug is not fixed. Contributor points or something, I don't know if you have that.

But anyway. I understand that it is a free software and you owe me nothing. Maybe someone should delete our posts on this question actually, since it is not really helpful to solving the issue and may discourage people from working on it when they see a lot of text to read :)

Regards.

[azaozz]

Isn't there some kind of order in which bugs are fixed relative to the order that they come in?

No. They are rather fixed in order of priority, i.e. if they are a regression, how severe the bug is, now many users are affected, if there is a patch, etc.

I understand that it is a free software and you owe me nothing.

That's not the case :)

Unfortunately I don't think this is fixable in core. Hidden elements in HTML don't have (browser calculated) dimensions. There is no way for TinyMCE (or any other JS) to get that hidden div's height simply because the browser doesn't know it. That can be done after it is shown.

Your best bet is to initialize TinyMCE on the same event used to show that div, right after you remove the display: none. Alternatively you can try setting the editor height (in the CSS) and then resize it after the div is shown.

[dangerd512]

Same problem...
'editor_height' also doesn't work if initializing it in hidden div...

[dangerd512]

As 'editor_height' doesn't works also, i'm think to reopen this issue...

[azaozz]

@dangerd512 could you install the example plugin from the ticket description and look at the editor iframe in the browser tools immediately after the page loads? As far as I see it has "proper" 300px height, same as the editor textarea. On clicking "SHOW IT" here the editor is shown with 300px height.

Re-reading the previous comments, for some reason I assumed the original reported bug was for setting the editor height "dynamically" according to the editor content height (which is not possible in this case, only at initialization of non-hidden editor instance).

However I cannot reproduce the editor not setting the height passed in the init array. The preset height works properly.

[dangerd512]

​http://files.dangerd.org/pub/!PUBLIC/wpbug.jpg

[azaozz]

Think I got to the bottom of it :)

Happens when we try to "close" the second row of toolbar buttons on initializing the editor. It looks at editor.iframeElement.clientHeight which, as the whole iframe is in a hidden div, is 0/not set. Then we increase it with 30px to compensate for the closed toolbar row. That's why the iframe height gets set to 30px but the textarea (where TinyMCE takes the height from) is still correctly set to 300px.

It's a small but annoying regression. Patch coming up.

[azaozz]

In 45461.diff:

• Don't adjust the editor (iframe) height on the initial hiding of the second, third, forth toolbar rows. This is done on editor init and breaks when the editor is initialized inside a hidden container.
• Adjust the resizing value a bit to better match the current (classic editor) styling.

Tested in Firefox, Chrome and Edge on Win10.

[pento]

Moving this to 5.2, as non-trunk regressions needed to be committed by 5.1 beta 2.

[nnikolov]

Great, thanks guys! Especially @azaozz for the fix. I tried it as well, and it worked when I made the changes in the plugin.min.js file.

[iseulde]

Looks good to me

[azaozz]

In 44832:

TinyMCE: fix editor height when loaded hidden.

Props nnikolov, azaozz.
Fixes #45461.