User Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/45.0.2454.101 Chrome/45.0.2454.101 Safari/537.36 Steps to reproduce: Click on Compose or Reply or Reply-All or Forward Actual results: Display shows 10 lines for addresses (plus one for Subject). (I did drag it to show 10 lines once, about two years ago, but it is impossible to drag it back to two) Expected results: Display should show two lines for addresses (as per config setting of mail.compose.addresswidget.numRowsShownDefault=2) Note this is similar to #425451 except for the number of lines: it's stuck at 10 but the config says 2.
I'd like to reproduce but your description is to vague for me. :-/ Can you, please, add a screenshot with marks what is showed incorrectly or how it shows be displayed? Thank you, Lars R.
My setting for mail.compose.addresswidget.numRowsShownDefault=3 I could not duplicate the problem using 38.3.0. I used the mouse to drag address lines to about 23 lines, and was able to drag it back to one. Closed the compose window, opened it again and had 3 address lines. Tested with both HTML and Plain Text composition windows. Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
Lars: It's in the office, so I'll screenshot it on Monday. Imagine you click Compose and get a Compose window with 10 lines for addresses, and the handle for dragging the address line block up (smaller) won't move up, only down. WaltS48, exactly; the only difference is that I dragged open the address line block to 10, finished work, and shut down Tbird and logged off. Ever since then it's been stuck on 10 lines.
Peter, please check if you have any addons installed and active. I don't think this is a TB bug. Try help > restart with addons disabled. Does the bug still occur with that? This is technically NOT similar to bug 425451; in that bug, I removed the hardcoded default minimum of 4 rows and replaced it with the pref mentioned above: mail.compose.addresswidget.numRowsShownDefault=3, while setting the hard-coded minimum to 1 row.
Lots :-) I disabled them in combinations until I found Theme Font and Size Changer. an obvious candidate which I should have spotted before. Disabling it reverts the interface to the default tiny fonts which my ailing sights can't read, but gets rid of the problem. Re-enabling it does not re-establish the problem, at least not for the moment. Thank you very much for pointing at what I ought to have found myself...
(In reply to Peter Flynn from comment #5) > Thank you very much... Most welcome. I'm happy to hear the pref gets used. Btw how did you find it? Would it help your usecase if this pref was exposed in options UI? If you would like to assist others in the same situation, you could try to contact the addon author and report this bug to him. I guess that the addon assumes the situation where minimum height was hardcoded and equal to default height, so maybe they pick the min-height when you install the addon, make it bigger to accommodate larger fonts, and then use that as new default height. So maybe when you installed the addon, coincidentally you had expanded the recipient field to 10 rows so the addon picked that? Thanks for swift cooperation. There are other users out there who just dump their complaints but never come back to reply when you ask for details.
Not clear what "the pref" refers to here... I reported this behaviour via the author's web page, at least for documenting it. I share your pain about users...I was a developer in another life (still do a little bit) but I have to deal with end users all day :-)