Ticket #19649 (assigned defect (bug))

Opened 5 months ago

Last modified 4 weeks ago

DFW Auto textarea lengthening is twitchy

Reported by: markjaquith Owned by: koopersmith
Priority: normal Milestone: Future Release
Component: Editor Version:
Severity: normal Keywords: needs-patch
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

19649.diff Download (512 bytes) - added by garyc40 5 months ago.
19649.2.diff Download (517 bytes) - added by garyc40 5 months ago.
19649.3.diff Download (582 bytes) - added by garyc40 5 months ago.

Change History

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

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

  • 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.

  • 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.

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: ↓ 8   garyc405 months 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

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

comment:8 in reply to: ↑ 6   azaozz4 weeks 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 4 weeks ago by azaozz (previous) (diff)
Note: See TracTickets for help on using tickets.