Closed Bug 1056404 Opened 10 years ago Closed 10 years ago

In addressing widget, only 2 recipient rows shown (including empty line) in spite of mail.compose.addresswidget.numRowsShownDefault=3; (caused by bug 966655)

Categories

(Thunderbird :: Message Compose Window, defect)

31 Branch
x86_64
Windows 8.1
defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: support, Unassigned)

References

Details

(Keywords: verifyme, Whiteboard: [fixed by bug 966655])

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.143 Safari/537.36

Steps to reproduce:

Using the new version 31.0, When entering an email address in the "To:" field then  pressing tab or enter.


Actual results:

The "To:" field immediately scrolled up (making the email address you just entered not visible) then a new To: field became visible (to enter another email address).


Expected results:

After entering the email address and pressing tab or enter, it would take you to the subject field but still allow you to see the email address that you entered in the To: field.
I have used the suggestion in:  https://support.mozilla.org/en-US/questions/1015411?esab=a&s=more+than+1+row+in+version+31.0&r=22&as=s
however, you have to do that with each email, it does not remain static, and defaults back to showing only 1 To: field. 

I have also checked the configuration and the addresswidget: mail.compose.addresswidget.numRowsShownDefault is set to 3.

Thanks! JP
JP, thanks for filing this bug, I like the cooperative style of comment 0. :)

I have just commented on the support thread you mentioned that there's a number of things going on here:

> 1) Before TB24, default number of rows for recipient are was 4. In TB24, we changed 
> this with my patch in Bug 425451 to become 3, assuming this will save precious 
> vertical space for a large number of private users, given that the entire header 
> area consumes a lot of screen real estate. For users who regularly use and want to 
> see more than 3 recipients at a time as a default, there's a hidden pref:
> Tools  Options  Advanced  General  Config Editor 
> mail.compose.addresswidget.numRowsShownDefault=3;
>
> 2) Since time immemorial, you can drag to manually expand the composition header 
> area for that specific message (not preserved because your next message will be 
> different; use default rows pref above). Before TB31, drag the splitter underneath 
> Subject field. From TB31 onwards, drag the bottom border of the composition header 
> area, i.e. the bottom border of the formatting toolbar in case of HTML messages.
>
> 3) There's a bug in TB31 (at least on Windows XP theme which I'm using) that the 
> vertical space of the widget was calculated too small; hence there's a scrollbar as 
> soon as you start a new message which shouldn't be there. As you add more addresses, 
> these few missing pixels will cause the 3rd row to never be visible UNLESS you 
> expand the widget manually as described in 2) above, or increase the default number 
> of rows, see 1). So you end up with a maximum of 2 visible rows at any time, which 
> will mostly be appear to be just 1 row because the blank row also counts (for more 
> details, see 4). I think we can morph Bug 1056404 to cover this issue.
>
> 4) In TB24, Enter in last recipient row confirmed that recipient and added a new 
> blank row; Tab would just move focus to the subject field. In TB31, Tab now behaves 
> like Enter, also creates a new row. There are pros and cons for that behaviour, but 
> we've heard from several users that they are not happy with this, so we're in the 
> process of reverting that change back to the old behaviour in Bug 1043784.
Richard, can you look into this please?

Recipient area defaults to 3 rows, but we don't offer enough vertical space for those 3 rows to fully fit without showing scrollbar (a few pixels are missing). As a result, when users start to fill in recipients, they'll never see more than 2 rows including the last empty row, so practically we show only 1 filled row and scroll up every time which makes a really unsteady and odd UX. Plus there's Bug 1043784 so even using TAB doesn't help to avoid trailing blank row.

I had already mentioned this to Josiah and you via PM dated 28-04-2014, but unfortunately haven't received any reply. I'm reusing the same screenshot here, pls ignore issues not relevant to this bug, only the red circle matters.
Flags: needinfo?(richard.marti)
The underlying problem is bug 966655, which claims to involve OS-wide dpi scaling.

JP, when you start a new message with less than 3 automatical cc/bcc recipients, do you see a scrollbar?
If yes, do you have dpi scaling set for your Windows system, so that the entire screen is magnified to avoid microscopic sizes on high-resolution screens? Which percentage?
Status: UNCONFIRMED → NEW
Depends on: 966655
Ever confirmed: true
Flags: needinfo?(support)
Summary: Number of Rows Displayed when composing New Email → In addressing widget, only 2 recipient rows shown (including empty line) in spite of mail.compose.addresswidget.numRowsShownDefault=3; (caused by bug 966655)
This looks like a rounding issue. On XP Classic I get quite good results with setting the border width to 2pt instead 2px (but not when scaling is 100%). On 125% the 2px borders are calculated in DONi with 1.6px and the 2pt borders with 2px. On XP normal the border change doesn't work but it works with setting a height for addressingWidgetItem and dummy-row of 25px (but again not always). On Win8 it works for scaling >=120% with a height of 2.15em.

Because it isn't the same on all OS versions it's very hard to clearly nominate a solution and also why it is failing. Maybe it is also a toolkit issue but we need a reduced testcase for this.
Flags: needinfo?(richard.marti)
(In reply to Thomas D. from comment #3)
> The underlying problem is bug 966655, which claims to involve OS-wide dpi
> scaling.
> 
> JP, when you start a new message with less than 3 automatical cc/bcc
> recipients, do you see a scrollbar?
> If yes, do you have dpi scaling set for your Windows system, so that the
> entire screen is magnified to avoid microscopic sizes on high-resolution
> screens? Which percentage?

Thomas, DPI scaling is set to at 100% for all displays. (No magnification). Yes, there is a scrollbar with less than 3 recipients.
Flags: needinfo?(support)
Can you attach a screenshot of a fresh composition without automatic cc/bcc and without touching the size of the header area manually? Make sure to black any private data from the screenshot.

Pls report the abosolute resolution of your screen, and the screen size in inches.
On the other bug, :paenglab reported that it was ok for Win 8 with 100%, so there must be something different with your setup.

Are you using TB's default theme? (check in addons / appearance)

I wrote and published patch for your issue on the other bug, perhaps it can be solved that way.
I'll classify this as major because the UX of this is really odd as it effectively (not unreversably, but still) cripples the default recipient area for every single composition.
Severity: normal → major
I've fixed this in bug 966655 and requested landing for release branches to really fix this major annoyance for consumers asap.
Status: NEW → RESOLVED
Closed: 10 years ago
Keywords: verifyme
Resolution: --- → FIXED
Whiteboard: [fixed by bug 966655]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: