Make WordPress Core

Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#33400 closed enhancement (fixed)

The post's textarea is breaking when is resized

Reported by: matheusfd's profile MatheusFD Owned by: chriscct7's profile chriscct7
Milestone: 4.4 Priority: normal
Severity: normal Version: 1.5
Component: Options, Meta APIs Keywords: needs-patch 2nd-opinion
Focuses: ui, administration Cc:

Description

When we need to resize the textarea, it's getting broken because it doesn't have a width limit.

I think the problem can be solved adding

resize: vertical to textarea's CSS

  • Chrome in OS X

http://tosaindo.com/wp-content/uploads/2015/08/Captura-de-Tela-2015-08-18-às-01.35.57.png

  • Mozilla Firefox in OS X

http://tosaindo.com/wp-content/uploads/2015/08/Captura-de-Tela-2015-08-18-às-01.41.01.png

Attachments (2)

33400.patch (336 bytes) - added by tyxla 9 years ago.
Limiting resizing to vertical on textarea fields in admin.
33400.2.patch (302 bytes) - added by MatheusFD 9 years ago.
Limiting resize and removing overflow: auto

Download all attachments as: .zip

Change History (22)

#1 @chriscct7
9 years ago

  • Version 4.2.4 deleted

#2 @MatheusFD
9 years ago

  • Version set to trunk

#3 follow-up: @valendesigns
9 years ago

You're saying that this is new behavior, specific to trunk?

#4 in reply to: ↑ 3 @MatheusFD
9 years ago

Replying to valendesigns:

You're saying that this is new behavior, specific to trunk?

No, it's not specific to trunk. I updated this because in the trunk version it's occurring too

#5 follow-up: @valendesigns
9 years ago

  • Component changed from Posts, Post Types to Options, Meta APIs
  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to Future Release
  • Version trunk deleted

The version number is to indicate when the bug was first introduced, and by setting it to trunk you would be saying that the bug is a regression that was introduced in trunk. It's very likely an old bug that has been around for many versions and you're just finding it now, or perhaps it is indeed new one. However, before setting the version number you would need to do some research to find out when it was introduced exactly.

Version 0, edited 9 years ago by valendesigns (next)

#6 in reply to: ↑ 5 @MatheusFD
9 years ago

Replying to valendesigns:

The version number is to indicate when the bug was first introduced, and by setting it to trunk you would be saying that the bug is a regression that was introduced in trunk. It's very likely an old bug that has been around for many versions and you're just finding it now, or perhaps it is indeed a new one. However, before setting the version number you would need to do some research to find out when it was introduced exactly.

I tested in v1.5.1 and the error was occurring too.

#7 follow-up: @valendesigns
9 years ago

  • Keywords good-first-bug added
  • Milestone changed from Future Release to 4.4
  • Owner set to valendesigns
  • Status changed from new to assigned
  • Version set to 1.5.1

Then it's an ancient artifact lol. Someone will create a patch for it in 4.4. Thanks for reporting the bug and verifying it's really really old. If you wanted to try your hand at creating a patch, this would be a great place to start.

#8 follow-up: @nicholas_io
9 years ago

Maybe we need to take a further look to see if there is any other textarea with the same problem within the WordPress Admin Panel.

Thanks @MatheusFD and congratulations for reporting this ancient bug.

#9 in reply to: ↑ 7 @MatheusFD
9 years ago

Replying to valendesigns:

Then it's an ancient artifact lol. Someone will create a patch for it in 4.4. Thanks for reporting the bug and verifying it's really really old. If you wanted to try your hand at creating a patch, this would be a great place to start.

It'll be a good place to start!! Sure I will try to fix it! Thanks!

#10 in reply to: ↑ 8 @MatheusFD
9 years ago

Replying to nicholas_io:

Maybe we need to take a further look to see if there is any other textarea with the same problem within the WordPress Admin Panel.

Thanks @MatheusFD and congratulations for reporting this ancient bug.

I tested with other textareas and they are with the same bug. I'll try to correct this. Thanks for remember!!

@tyxla
9 years ago

Limiting resizing to vertical on textarea fields in admin.

#11 @tyxla
9 years ago

  • Keywords has-patch added; needs-patch removed

The supplied patch fixes the issue on all locations where the textarea fields were breaking on horizontal resize.
Some of them are:

  • Post: Excerpt field textarea
  • Post: Custom Fields textarea
  • Taxonomy description field
  • General -> Writing: Update Services
  • General -> Discussion: Comment Moderation, Comment Blacklist
  • User Profile -> Bio
  • Theme / plugin editor
  • Textarea fields in widgets
  • Comment text field in Add/reply to/edit comments in various admin locations
  • Media: attachment caption & description fields

#12 @chriscct7
9 years ago

  • Keywords needs-testing added; good-first-bug removed
  • Owner changed from valendesigns to chriscct7
  • Status changed from assigned to reviewing
  • Version changed from 1.5.1 to 1.5

#13 @chriscct7
9 years ago

Looks good so far. Will do some more testing tomorrow on this.

#14 @MikeHansenMe
9 years ago

Looks good to me.

#15 @MatheusFD
9 years ago

In my tests, I removed overflow: auto; and it worked well. It was tested in IE 9.0, Mozilla Firefox Developer Edition 42.0a2 and in Google Chrome version 44.0.2403.155 m. In all this browsers, the overflow: auto was not necessary. What do you all think about? Less code, fast load :)

Last edited 9 years ago by MatheusFD (previous) (diff)

@MatheusFD
9 years ago

Limiting resize and removing overflow: auto

#16 @helen
9 years ago

I imagine overflow: auto was put there to hide scrollbars in IE until they're absolutely needed. Perhaps newer IE has different behavior, but would like a before/after comparison in IE 8 and a newer version if behavior is different, even if just for documentation.

#17 follow-up: @wonderboymusic
9 years ago

  • Keywords needs-patch added; has-patch needs-testing removed

#18 in reply to: ↑ 17 @MatheusFD
9 years ago

  • Keywords 2nd-opinion added

Replying to wonderboymusic:

http://caniuse.com/css-resize

So, can't we use resize: vertical because it doesn't work in some browsers? If we follow this way, we can't use unicode-bidi too (http://caniuse.com/#search=unicode-bidi), that we can find in commom.css

About overflow: auto you were correct, @helen, it's to show the bar only when needed.

#19 @helen
9 years ago

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

In 33890:

UI: Restrict textarea resizing to vertical to prevent ugliness.

props tyxla, MatheusFD.
fixes #33400.

#20 @johnbillion
9 years ago

#33399 was marked as a duplicate.

Note: See TracTickets for help on using tickets.