#33400 closed enhancement (fixed)
The post's textarea is breaking when is resized
Reported by: |
|
Owned by: |
|
---|---|---|---|
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 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?