| Issue 1145: | Description textarea grows 1 line with every character typed while editing it in Chromium for Linux | |
| 16 people starred this issue and may be notified of changes. | Back to list |
*NOTE: Do not post confidential information in this bug report.* What version are you running? Whatever's currently in production at VMware. What's the URL of the page containing the problem? Seems to affect any review. What steps will reproduce the problem? 1. Try to edit the description field of a review in Chromium for Linux. What is the expected output? What do you see instead? I expect the text area to only expand when I autowrap to a new line. Instead it does so every time I type a new character. What operating system are you using? What browser? Chromium 3.0.183.0 on Ubuntu 9.04 Please provide any additional information below. It's possible this is a Chromium bug but it doesn't seem to happen on any other webapps.
Comment
2
by
sebastie...@gmail.com,
Jun 3, 2009
,
Jun 3, 2009
There are a lot of issues with textareas and the version of WebKit that Chrome is using. It's not just us. We found a forum of people all complaining about similar issues. For 1.0, we are not officially supporting Chrome at all. We recommend Firefox for the best experience. As Chrome matures, we will consider adding it to the support list.
Status: Confirmed
Labels: -Priority-Medium Priority-Low Browser
,
Jun 11, 2009
Here is the Chromium issue: http://code.google.com/p/chromium/issues/detail? id=10829&q=textarea row&colspec=ID And the WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=25938
,
Jun 11, 2009
I think it's safe to say this is not our bug :)
Status: ThirdParty
,
Jul 14, 2009
Issue 1219 has been merged into this issue.
,
Jul 14, 2009
Issue 1170 has been merged into this issue.
,
Jul 14, 2009
Issue 1208 has been merged into this issue.
,
Sep 2, 2009
Issue 1262 has been merged into this issue.
,
Sep 2, 2009
It should however be mentioned that Facebook's growing comment area works properly with Chrome -- i.e. a solution exists, even if a workaournd needs to be implemented in jQuery.
,
Sep 9, 2009
Issue 1303 has been merged into this issue.
,
Sep 10, 2009
Issue 1306 has been merged into this issue.
,
Sep 17, 2009
I made this change in djblets, which seems to fix the problem for me. djblets/media/js/jquery.gravy.js: - newHeight = this.element[0].scrollHeight; + newHeight = this.element[0].scrollHeight + (this.element.height() - this.element[0].clientHeight); scrollHeight apparently corresponds to clientHeight, which differs from height() in chrome but not firefox, for me. So...I removed the difference, which I presume is constant and just due to padding.
,
Sep 17, 2009
Hmm, interesting. We'd definitely need to test this at least on Chrome, Safari, IE and Firefox. Have you then tested in both Chrome and Firefox? And it works in both?
Status: NeedInfo
,
Sep 17, 2009
Yes, it fixes the issue in both Chrome[ium] and Firefox in Windows and Linux for me. I just grabbed Safari for Windows, and I can't reproduce it in an unpatched install. Not really sure what's going on there. Someone who's not me should definitely try it. :)
,
Oct 3, 2009
Fixed in Djblets on master (r61810c1). Thanks Cory!
Status: Fixed
Owner: chipx86 Labels: -Priority-Low Priority-Medium Djblets Milestone-Release1.0.x
,
Oct 27, 2009
This does not appear to be fixed in 1.0.5.1. Is there any interest in applying this fix for 1.0.x?
,
Nov 14, 2009
Weird, this does *not* happen on my install of ReviewBoard after a recent update to a Nightly. However, this still does happen on http://reviews.reviewboard.org. Has http://reviews.reviewboard.org been updated?
,
Nov 14, 2009
No, not for a little while. I'll be doing an update pretty soon, but I'm waiting to get a couple more changes in first. |
|
| ► Sign in to add a comment |