Make WordPress Core

Opened 10 years ago

Closed 10 years ago

#28000 closed defect (bug) (fixed)

Editor frame becomes huge after dragging the corner to resize it

Reported by: jupiterwise's profile jupiterwise Owned by: nacin's profile nacin
Milestone: 3.9.1 Priority: normal
Severity: normal Version: 3.9
Component: Editor Keywords: fixed-major
Focuses: javascript Cc:


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.

Attachments (1)

28000.diff (497 bytes) - added by jupiterwise 10 years ago.
Wrap the toolbarHeight measurement in a parseInt()

Download all attachments as: .zip

Change History (18)

10 years ago

Wrap the toolbarHeight measurement in a parseInt()

#1 @jupiterwise
10 years ago

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.

Props to tollmanz for helping to track this down.

Last edited 10 years ago by jupiterwise (previous) (diff)

#2 @azaozz
10 years ago

  • Milestone changed from Awaiting Review to 3.9.1
  • Version changed from trunk to 3.9

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.

#3 @azaozz
10 years ago

In 28193:

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

#4 @azaozz
10 years ago

  • Keywords fixed-major added

#5 @nacin
10 years ago

  • Owner set to nacin
  • Resolution set to fixed
  • Status changed from new to closed

In 28200:

Ensure the editor height is saved properly as an integer.

Merges [28193] to the 3.9 branch.

props jupiterwise.
fixes #28000.

#6 @kinderr@…
10 years ago

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:



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



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.



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.


Last edited 10 years ago by SergeyBiryukov (previous) (diff)

#7 follow-up: @kinderr@…
10 years ago

I added the diff change to post.js listed here: 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?


#8 @SergeyBiryukov
10 years ago

#28069 was marked as a duplicate.

#9 in reply to: ↑ 7 @SergeyBiryukov
10 years ago

Replying to kinderr@…:

I added the diff change to post.js listed here: 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:

#10 @kinderr@…
10 years ago

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?


#11 @richards1052
10 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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?

Last edited 10 years ago by richards1052 (previous) (diff)

#12 @jupiterwise
10 years ago

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?

#13 follow-up: @richards1052
10 years ago

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!

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.

Last edited 10 years ago by richards1052 (previous) (diff)

#14 in reply to: ↑ 13 @azaozz
10 years ago

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").

#15 @richards1052
10 years ago

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.

Last edited 10 years ago by richards1052 (previous) (diff)

#16 @kinderr@…
10 years ago

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.

#17 @nacin
10 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.