#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: |
Attachments (2)
Change History (22)
#4
in reply to:
↑ 3
@
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:
↓ 6
@
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 a new one. However, before setting the version number you would need to do some research to find out when it was introduced exactly.
#6
in reply to:
↑ 5
@
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:
↓ 9
@
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:
↓ 10
@
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
@
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
@
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!!
#11
@
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
@
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
#15
@
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 :)
#16
@
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.
#18
in reply to:
↑ 17
@
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 useunicode-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.
You're saying that this is new behavior, specific to trunk?