WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 5 years ago

#28000 closed defect (bug) (fixed)

Editor frame becomes huge after dragging the corner to resize it

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

Description

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 5 years ago.
Wrap the toolbarHeight measurement in a parseInt()

Download all attachments as: .zip

Change History (18)

@jupiterwise
5 years ago

Wrap the toolbarHeight measurement in a parseInt()

#1 @jupiterwise
5 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.

Version 0, edited 5 years ago by jupiterwise (next)

#2 @azaozz
5 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
5 years ago

In 28193:

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

#4 @azaozz
5 years ago

  • Keywords fixed-major added

#5 @nacin
5 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@…
5 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:

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

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

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

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

#8 @SergeyBiryukov
5 years ago

#28069 was marked as a duplicate.

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

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

#10 @kinderr@…
5 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?

Thanks

#11 @richards1052
5 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 5 years ago by richards1052 (previous) (diff)

#12 @jupiterwise
5 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
5 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!

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.

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

#14 in reply to: ↑ 13 @azaozz
5 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
5 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 5 years ago by richards1052 (previous) (diff)

#16 @kinderr@…
5 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
5 years ago

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