Editor frame becomes huge after dragging the corner to resize it

[jupiterwise]

When resizing the Editor frame any amount the value that is saved to usermeta is missing a crucial decimal point, thereby causing the Editor to be excessively tall upon a page refresh.

To reproduce:

• Edit an existing post or page, or create a new one
• Adjust the height of the Editor frame a few pixels by clicking and dragging the bottom right corner. The height will stick where you left it.
• Click Update or just reload the page. When the reload is complete the Editor frame will be really, really tall.

[jupiterwise]

Wrap the toolbarHeight measurement in a parseInt()

[jupiterwise]

Adding the parseInt() ensures that the ed_size value is already a whole integer before it has non-digit characters (such as a decimal point) stripped from it.

[azaozz]

Nice catch. If jQuery( element ).height() returns a float, it sets the height properly but when saved with setUserSetting( 'ed_size', height );, the dot is stripped, making it completely different.

[azaozz]

In 28193:

Ensure the editor height is saved properly, props jupiterwise, see #28000, for trunk.

[nacin]

In 28200:

Ensure the editor height is saved properly as an integer.

Merges [28193] to the 3.9 branch.

props jupiterwise.
fixes #28000.

[kinderr@…]

I've encounter a very similar problem with a huge editor size after upgrading to WP 3.9.

========== New Symptoms ========

Upgraded to WP 3.9 and everything is working fine except an old bug reported in WP 3.5 is back: #23042

1st scenario: Logged in as Editor
When I create a new post the editor text area is ~9 pages in height with no scroll bar. BTW - the post editor width is fine. If I manually drag the editor window control in the lower right corner to reduce the number of lines in the window it's fine until I save the post... the post editor is back to a huge vertical size.

Running getUserSetting('ed_size') from the FireBug Javascript console in FireFox 28.0 results:

Created a new post results in a huge editor text area:

getUserSetting('ed_size');

"444266667"

After manually resizing to the editor area to about 1 screen in height - the editor scroll bar now showing:

getUserSetting('ed_size');

"535266667"

Obviously the editor size numbers are invalid.

Same issue when editing posts Chrome 34.0.1847.116 m.

2nd Scenario: Logged in as Administrator
The post editor works fine and there's never a problem with the vertical window size after saving a post.

getUserSetting('ed_size');

"558"

3rd Scenario: Logged in as Administrator in a new browser session; cleared the browser cache and cookies

The post editor window height is now huge whether logged in as Editor or Administrator. I can manually resize the editor window just fine via the lower right corner handle, but it doesn't keep the new window height after saving the post draft.

Let me know if you need more debug info.

Thanks
Robert

[kinderr@…]

Hi,
I added the diff change to post.js listed here: https://core.trac.wordpress.org/attachment/ticket/28000/28000.diff to my WordPress 3.9 install and the editor height problem persists.

Maybe this is a different bug and I should open a new ticket?

Thanks

[SergeyBiryukov]

#28069 was marked as a duplicate.

[SergeyBiryukov]

Replying to kinderr@…:

I added the diff change to post.js listed here: https://core.trac.wordpress.org/attachment/ticket/28000/28000.diff to my WordPress 3.9 install and the editor height problem persists.

You need to add SCRIPT_DEBUG constant to your wp-config.php file to use unminified files:
​http://codex.wordpress.org/Debugging_in_WordPress#SCRIPT_DEBUG

[kinderr@…]

I upgraded to WordPress 3.9.1 today and the text editor height bug remains. Should I create a new ticket? What debug information is needed?

Thanks

[richards1052]

Agree with Kinderr. I applied the hack by changing the box height from 5000. But upgrading WP reverted the file to the former 5000 line height. Would really love this fix to get into the next update. It's a drag to have to fix a bug with every WP update.

I don't understand why this bug is marked "fixed" when it's not. Because it was marked "fixed" I opened a new ticket, which was closed & marked as a duplicate of this bug. It is. But if this is marked fixed how will anyone know it's not?

[jupiterwise]

I just re-checked this on a live site running 3.9.1, and I'm not seeing the issue. The code fix was in a JavaScript file, which gets pretty aggressively cached in the WordPress admin. Did you try clearing your browser cache and then doing a hard refresh on the Post edit screen?

[richards1052]

I applied a hack to the includes/class-wp-editor.php file (see link below). The post box sized properly. Then I upgraded to 3.9.1. That wiped out the hack to the file and the post box reverted to the 5000 line size. So I doubt this has anything to do with clearing the browser cache and doing a hard refresh since everything was working fine until I upgraded. Upgrading didn't fix the bug as it was supposed to--it caused the bug to reappear!

​http://wordpress.org/support/topic/edit-box-has-gotten-enormously-long-and-setting-for-it-is-gone?replies=14#post-3647240

But I'll wait to see what happens during the next upgrade. The file will surely revert. When it does I'll try clearing the cache, etc. If that doesn't work, then something's still buggy.

[azaozz]

Replying to richards1052:

I applied a hack to the includes/class-wp-editor.php file...

That's not a good way to reset the height. Best is to drag the corner in either Visual or Text mode. Alternatively you can run this line of JS from the browser console:

setUserSetting('ed_size', 300);

then reload the page. (To get to the browser console press F12, select "Console" from the tabs, paste the above line and press Enter or click "Run").

[richards1052]

Of course I know how to change the size by dragging. But the problem with this bug is that it will resize the box back to 5000 lines when the post box reopens. I don't want the hassle of having to do this every time I open that page.

I'll check out the browser console/js option. But if this method doesn't cause the box to remain at 300 & it reverts to 5000, then it won't be useful.

I use Firefox. When I click F12 it opens Firebug. When I click Console it opens a box into which I can't paste anything. I added a check next to the Show Command Editor and a new box opened into which I entered your code. But when I click Enter nothing happens and there is no Run command.

UPDATE: Woops. I see the Run command is at the bottom of the editor box. I got it right finally. Let's see if that fixes it when the next WP upgrade happens and the file to which I added the hack reverts.

Thanks for your suggestion.

[kinderr@…]

I believe the editor height bug is related to cookies. After configuring FireFox 29.0.1 on Windows 7 to NOT accept 3rd party cookies the editor height is consistently a normal default size.