WordPress.org

Make WordPress Core

Opened 2 years ago

Last modified 2 years ago

#19649 assigned defect (bug)

DFW Auto textarea lengthening is twitchy

Reported by: markjaquith Owned by: koopersmith
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Editor Keywords: needs-patch
Focuses: Cc:

Description

The auto textarea lengthening is twitchy. It shoves the content up a line, then pulls it back down.

Best seen in a screencast: http://screencast.com/t/e5zIpkk9nY

Attachments (3)

19649.diff (512 bytes) - added by garyc40 2 years ago.
19649.2.diff (517 bytes) - added by garyc40 2 years ago.
19649.3.diff (582 bytes) - added by garyc40 2 years ago.

Download all attachments as: .zip

Change History (11)

comment:1 markjaquith2 years ago

  • Owner set to koopersmith
  • Status changed from new to assigned

comment:2 azaozz2 years ago

Seems browser specific: doesn't happen in FF, sometimes in Chrome (win) and IE.

comment:3 garyc402 years ago

  • Keywords has-patch needs-testing added

This happens all the time for me in Chrome Mac.

The reason why it's that way is because the textarea new size does not provide enough space for the new line. Line-height of the text area is 19px (1.625em). Adding 19px to the resized height eliminate this issue for me.

Attached is a patch. Please test.

garyc402 years ago

garyc402 years ago

comment:4 garyc402 years ago

  • Keywords has-patch needs-testing removed

Ignore the naive patches. They don't work.

Basically what's going on in m browser is:

  • When \n is inserted, the textarea automatically scroll, so the first line became out of view.
  • After that, the auto-resize mechanism kicks in, and resizes the textarea properly, which then restores the first line and makes the text area jump a bit.

comment:5 garyc402 years ago

Just wanna confirm that this is not happening in Gecko, just Webkit.

Somehow in Webkit, the scrolling happens before "keyup" event is fired.

There's just no clever work-around for this as far as I know. Of course we could use a contentEditable body inside an iframe (just like the visual edit box) instead of a textarea, but that would be an overkill.

comment:6 follow-up: garyc402 years ago

  • Keywords has-patch needs-testing added

OK, this CSS trick fixes it. Add 19px to the bottom padding of the text area (and subsequently subtract 19px from the container's padding).

Attached patch

garyc402 years ago

comment:7 nacin2 years ago

I would really like to fix this. It is incredibly distracting when using DFW.

comment:8 in reply to: ↑ 6 azaozz2 years ago

  • Keywords needs-patch added; has-patch needs-testing removed
  • Milestone changed from 3.4 to Future Release

Replying to garyc40:

OK, this CSS trick fixes it.

Unfortunately it also hides the last line when the text is longer and doesn't fit in the initial height of the textarea.

Last edited 2 years ago by azaozz (previous) (diff)
Note: See TracTickets for help on using tickets.