Make WordPress Core

Opened 10 years ago

Closed 10 years ago

#29307 closed defect (bug) (fixed)

Editor height jumps three times before it has its final height

Reported by: ocean90's profile ocean90 Owned by:
Milestone: 4.0 Priority: normal
Severity: normal Version: 4.0
Component: Editor Keywords: has-patch commit
Focuses: ui, javascript Cc:

Description

Related: #28328

While creating a new post, the editor height jumps three times before it has its final height: First height seems to be from the user setting, then it jumps to the editor min height (300px?) after that the editor is pinned to the bottom and at last it has the min height again. Tested in Chrome 36 and Firefox 31 on OSX.

Screencast: https://cloudup.com/iSS8TXBnOVt

Attachments (4)

29307.patch (1.7 KB) - added by iseulde 10 years ago.
29307.2.patch (2.1 KB) - added by iseulde 10 years ago.
29307.3.patch (2.8 KB) - added by iseulde 10 years ago.
29307.4.patch (2.3 KB) - added by iseulde 10 years ago.

Download all attachments as: .zip

Change History (19)

#1 @ocean90
10 years ago

  • Keywords needs-patch added

#2 @azaozz
10 years ago

This is actually pretty tough to trace. Caused by the interaction between editor-expand.js and wpautoresize, both running several times on loading the page.

The only way around seems to be to set the wrapper to height: 300px; overflow: hidden; from the very beginning and remove after everything has loaded, however this would cause problems if there are any other errors while loading (potentially can "lock-out").

#3 @nacin
10 years ago

This is pretty painful to watch. Anything we can do here?

This ticket was mentioned in IRC in #wordpress-dev by helen. View the logs.


10 years ago

#5 follow-up: @markoheijnen
10 years ago

I'm curious if we still need the user setting.

#6 in reply to: ↑ 5 @iseulde
10 years ago

Replying to markoheijnen:

I'm curious if we still need the user setting.

It can still be disabled. And the visible resizing actually happens because it tries to resize multiple times, to make sure the editor has the right height with all CSS loaded, not because of that setting.

#7 @stephdau
10 years ago

I tried to come up with some alternative fixes, but they all boil down to having the same caveats as the ones azaozz listed above.

#8 @iseulde
10 years ago

We should be able to fix this. It's not the wpautoresize plugin doing this. That one only resizes the editor once: console.log( resizeHeight, oldSize ); where resizeHeight = 300 and oldSize = 0 (not the actual old size but previously stored resizeHeight, which is 0 the first time).

For me, when I go to the new post screen, the editor resizes from big -> normal -> big -> normal. (And wpautoresize only hits once here.) Removing the height from the textarea gives me: supersmall -> normal -> big -> normal. (normal = 300px). So there's something else resizing the editor.

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

#9 @iseulde
10 years ago

So the first "abnormal" height is the user setting. Trying to find out where the second one is coming from...

@iseulde
10 years ago

@iseulde
10 years ago

#10 @iseulde
10 years ago

Just trying some things here... If we set the editor height to 300 when 'expand' is enabled, the first jump is less severe (you can still see it a bit, but that's the toolbar suddenly appearing). If we also check if the editor is empty before resizing, it seems to be gone? Still not sure what it resizes to such a big height at first.

@iseulde
10 years ago

#11 @iseulde
10 years ago

.3: Also prevent textarea resizing when the initial editor mode is tinymce and tinymce is not yet initialised.

@iseulde
10 years ago

#12 @iseulde
10 years ago

  • Keywords has-patch added; needs-patch removed

#13 follow-up: @ocean90
10 years ago

  • Keywords commit added

29307.4.patch looks good. There is still a jump, but it's the same as in 3.9.

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

Replying to ocean90:

29307.4.patch looks good. There is still a jump, but it's the same as in 3.9.

Yeah, I'm pretty sure that's the toolbars popping up from nowhere.

#15 @helen
10 years ago

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

[29628] missed the ticket.

Note: See TracTickets for help on using tickets.