WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#33400 closed enhancement (fixed)

The post's textarea is breaking when is resized

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

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 4 years ago.
Limiting resizing to vertical on textarea fields in admin.
33400.2.patch (302 bytes) - added by MatheusFD 4 years ago.
Limiting resize and removing overflow: auto

Download all attachments as: .zip

Change History (22)

#1 @chriscct7
4 years ago

  • Version 4.2.4 deleted

#2 @MatheusFD
4 years ago

  • Version set to trunk

#3 follow-up: @valendesigns
4 years ago

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

#4 in reply to: ↑ 3 @MatheusFD
4 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
4 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 a new one. However, before setting the version number you would need to do some research to find out when it was introduced exactly.

Last edited 4 years ago by valendesigns (previous) (diff)

#6 in reply to: ↑ 5 @MatheusFD
4 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
4 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
4 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
4 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
4 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
4 years ago

Limiting resizing to vertical on textarea fields in admin.

#11 @tyxla
4 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
4 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
4 years ago

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

#14 @MikeHansenMe
4 years ago

Looks good to me.

#15 @MatheusFD
4 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 4 years ago by MatheusFD (previous) (diff)

@MatheusFD
4 years ago

Limiting resize and removing overflow: auto

#16 @helen
4 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
4 years ago

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

#18 in reply to: ↑ 17 @MatheusFD
4 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
4 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
4 years ago

#33399 was marked as a duplicate.

Note: See TracTickets for help on using tickets.