User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.81 Safari/537.36 Steps to reproduce: I changed the amount of address lines in compose window to 1 config: mail.compose.addresswidget.numRowsShownDefault=1 Actual results: But now I can't select the suggested email address with return key I have to use left mouse button. Annoying Expected results: I should have been able to select the email address with the return key instead. This does not happen when you use 2 lines: config: mail.compose.addresswidget.numRowsShownDefault=1

Well, Enter WILL correctly confirm the address and add a new blank row which gets focus, so the previously entered recipient is still there but out of view as you only see the new blank row. You can verify that any time by dragging the recipient area bigger, just grab the bottom border of the formatting toolbar. If you only have enter a single recipient and you don't want that one to disappear, press TAB instead of Enter, to avoid creating the new blank row. Then single recipient will be confirmed AND remain in view which is just fine. So to that extent, this bug would be invalid. If you insist on mail.compose.addresswidget.numRowsShownDefault=1 but still add multiple addresses, they will all be added correctly, but you'll only ever see one at a time, or none (more often than not). If you change your windows mouse wheel settings to only scroll one row at a time, you can use the mouse wheel to go through addresses line by line. Admittedly, shrinking a multi-row design into a single-row view-frame is probably a bad idea, but we allow it anyway for those with small screens or other reasons to minimize the vertical space needed for recipients, and maximise space for draft body. Btw, there's an RFE to remove the multi-row design and normalize the header area like most other mailers who have multiple addresses in a single row. Now to the bugs in this corner: - page up / page down seems to work sometimes (esp. down), but randomly stops working or doesn't work at all - we don't allow cursor up/down to navigate addresses, which is not a bug, but inconvenient. - tab/shift tab works better, but there are bugs of focus indication (blue highlight not coming for shift+tab with single row, but comes with multiple rows shown). - Pressing Enter in single-row mode, but having multiple addresses, say 3, will make your focus invisible and jump to the 3rd address, skipping the second row for no apparent reason. in multi-line view, it behaves normally going row by row. - there's no scrollbar when only one row is shown but there are multiple rows; this has to do with the size of the up and down arrow icons, but I'd argue there should be an extra smaller variant of those to handle the single-line case correctly. I think your best bet is to use the techniques/workarounds above, or simply mail.compose.addresswidget.numRowsShownDefault=2. It's unlikely somebody has the time or will to look into this, as it's an edge case which is not very useful nor frequent and can only occur with hidden configuration. It's hardly worth it if we plan to change the design anyway. Although it's worrisome how hackish this recipient thing behaves...

I'll confirm this multi-bug for now to keep those issues on the radar until we'll change the recipient area one day.

Thomas, I'm confused - I thought that mail.compose.addresswidget.numRowsShownDefault=2 was the minimum value, thus avoiding the issues associated with mail.compose.addresswidget.numRowsShownDefault=1?

(In reply to Thomas D. from comment #1) > Well, Enter WILL correctly confirm the address and add a new blank row which > gets focus, so the previously entered recipient is still there but out of > view as you only see the new blank row. You can verify that any time by > dragging the recipient area bigger, just grab the bottom border of the > formatting toolbar. > Ok, I understand. NOW that you explained it to me. Nonetheless it's a confusing behavior which leads to the impression that there is a bug. Hence it is a flaw. The new added line should now be moved to the bottom with the filled row still in view.

(In reply to 1manfactory from comment #4) > Ok, I understand. NOW that you explained it to me. > Nonetheless it's a confusing behavior which leads to the impression that > there is a bug. Hence it is a flaw. The new added line should now be moved > to the bottom with the filled row still in view. That will be equally confusing for other users who still want to add more recipients, and we'd create behaviour exceptions (like not moving focus into new line, only for defaultrows=1) which isn't good. Other users might then ask how to add another recipient... I agree with you the UX isn't good, and I've pointed out respective flaws above, but it's just a fact that limiting a multi-row-design to only one visible row can never provide good UX. I think it's more like we allow this so that users can reduce the space for recipients AFTER having added their recipients. Defaulting to 1 row is not recommended, so users will do that at their own risk and if they know how to tweak this hidden pref, we expect them to know how to handle the consequences... ;)

(In reply to rsx11m from comment #3) > Thomas, I'm confused - I thought that > mail.compose.addresswidget.numRowsShownDefault=2 was the minimum value, thus > avoiding the issues associated with > mail.compose.addresswidget.numRowsShownDefault=1? No, we eventually decided to allow numRowsShownDefault=1 in Bug 425451. We also allow reducing the recipient pane by dragging to 1 row. I believe both of this is OK: - users tweaking hidden prefs can be expected to know what they want; coding and explaining a minimum of 2 default rows doesn't seem to be worth it - users who *drag* header area to be smaller will also know what they are doing, and they can drag it bigger at any time the same way they reduced it before - Given the enormous amount of vertical space eaten by the header pane, it is a likely scenario not only for small screens that users want to shrink this as far as possible, especially *after* adding recipients