User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release) Build ID: 20140117030207 Steps to reproduce: On firefox 29 , when I input some contents into the input area of "google translate" https://translate.google.com/?hl=zh-TW&tab=wT#en/zh-TW/ . Actual results: The input area of "google translate" can't expand automatically as the input contents size exceeds the original input area size. Expected results: The input area of "google translate" should expand automatically to accommodate and show all words of the input contents.

Confirmed, regression Last good nightly: 2014-01-16 First bad nightly: 2014-01-17 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=324e2cba1029&tochange=9bcc52594322

Regression window(m-i) Good: http://hg.mozilla.org/integration/mozilla-inbound/rev/994659cbc145 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 ID:20140115185609 Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/36e4fcbd07d3 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 ID:20140115192806 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=994659cbc145&tochange=36e4fcbd07d3 Regressed by: 36e4fcbd07d3 Alex Henrie — Bug 157846. Main patch: Propagate text <input> padding down to its scrolled child and add 1px left/right padding to stylesheets as needed. Fix tests. r=roc Original patch by Charly Molter. Help from Robert O'Callahan and Jim Mathies.

Unfortunately, I was unable to decipher the minified Google JavaScript, so I wasn't able to put together a test case for this bug. I created the attached patch by looking at the previous code and then trial-and-error with Google Translate. This patch fixes Google Translate, but breaks some tests: https://tbpl.mozilla.org/?tree=Try&rev=6a17e8a95e09

That patch doesn't look right to me. I'm not sure why it fixes Translate. I haven't made any progress on this yet. We need to figure out how Translate actually does its textarea resizing thing. When it's working, it's setting style.height on the textarea; with the regression it never sets style.height to anything other than the initial value of 105px. I presume it's getting metrics from somewhere to decide what to set that height to, but I checked scrollHeight of the textarea and that seems OK. It's strange that even pasting very long text into the textarea doesn't make it enlarge the textarea.

They set the font-family and size on the textarea in the stylesheets. I wonder if they copy the text out of there into a separate element for measurement.

I tried to reduce the translate page to the input area. I'm removing the 'qawanted' keyword, but I'm leaving 'testcases-wanted' in case someone wants to go further. Once saved on the disc, the characters in the input area are moved up after it's size is exceeded (the same thing happens also with the original page).

That page doesn't seem to have any scripts in it. The scripts on the Translate page are the key here.

Hi Robert, So this seems like it would have a small impact on our users do you feel this needs tracking?

This is a critical bug, it makes Google Translate much less usable. If we can't fix it we'll need to back out the original patch.

Tracking based on Comment 9 would be great to have someone assigned here.

Bug 965237 should fix this...

Removing keyword per comment 6...

Fixed in Nightly since 2014-02-23, in bug 965237 / bug 966992. Please verify.

Verified fixed in nightly 30.0a1(2014-02-27) on Win 7, Mac OS X 10.8.5, Ubuntu 13.04.

(In reply to Mats Palmgren (:mats) from comment #13) > Fixed in Nightly since 2014-02-23, in bug 965237 / bug 966992. Looks like those two bugs landed on 29, so marking this accordingly.

Paul, can you please verify this on Firefox 29 too?

(In reply to Paul Silaghi, QA [:pauly] from comment #14) > Verified fixed in nightly 30.0a1(2014-02-27) on Win 7, Mac OS X 10.8.5, > Ubuntu 13.04. Reproduced in Nightly 2014-01-17. Verified fixed 29.0a2 (2014-03-10), Win 7 x64.