When adding a lot of recipients, the container don't have a max height 1. Add a lot of recipients 2. Tap to focus on Message field 3. Swipe down on recipients container 4. The container don't have max height See screenshots

Probably a regression from bug 949457. I remember I wanted to check this but forgot ;)

triage: in this case, users are not able to type message

Borja is currently working on other bugs so releasing "assigned" field in order to allow anyone else to pick this one up.

I could take a look first.

I think we can have a fixed max-height using "calc(100% - XXXrem)".

(In reply to Julien Wajsberg [:julienw] from comment #8) > I think we can have a fixed max-height using "calc(100% - XXXrem)". Sadly, it's not working because the container height is expanded by list, so setting percentage has no effect here. I think that's why we apply js solution for the max height computation before. I'll try any posibble css solution first.

Maybe using the vh unit then? Lile calc(100vh - XXXrem) ?

vh unit saves my day, thanks!

Hey Victoria, I'd like to know if the max-height is correctly set, or should it be a little smaller. Or should we wait for the final composer refresh to decide exactly?

Comment on attachment 8427086 [details] 2014-05-22-17-57-45.png The to field should never overlap the input area, but only in the new message case, we don't need to leave a gap btween the to field and the input. Moreover, the "to" word and the "+" button should stay at the bottom of the field since the new recipient will be placed there.

(In reply to Victoria Gerchinhoren [:vicky] from comment #13) > Comment on attachment 8427086 [details] > 2014-05-22-17-57-45.png > > The to field should never overlap the input area, but only in the new > message case, we don't need to leave a gap btween the to field and the > input. So like I thought, we need the max-height to be somewhat smaller, thanks ! > Moreover, the "to" word and the "+" button should stay at the bottom of the > field since the new recipient will be placed there. The To/+ issue will be done in the more general bug 963018.

Comment on attachment 8426142 [details] Link to github Removing the review request then, the value needs to be a little smaller. Maybe we should wait for bug 963018 though...

Victoria, can you give us precisely how much space we need to leave at the bottom, to see the input correctly? Thanks!

(In reply to Julien Wajsberg [:julienw] from comment #16) > Victoria, can you give us precisely how much space we need to leave at the > bottom, to see the input correctly? Thanks! Hi Julien, Isn't the input comming from BBs? Anyways, the height of that input should be 3.5 rem. Thanks!

Hi Vicky, I adjust the height of recipient container a little bit(considering the 3.5rem composer height you said). Does it looks better than old one?

Comment on attachment 8429904 [details] 2014-05-22-20-51-58.png Please, make it 3.7 rem. thanks!

Hi Vicky, since the actual height of recipient list is 4 rem, I take screenshot for both case(3.7rem and 4 rem to the bottom) and let you decide which is better.

Comment on attachment 8426142 [details] Link to github Adjust bottom space to 3.7 rem for showing composer since visual prefers this value.

Comment on attachment 8426142 [details] Link to github I think you need to check with a newer master because your screenshots does not take the composer refresh (landed last week) into account. As a result, it seems 3.7rem is very too big (it's about 2 lines), from my investigations I think it should be 2.2rem instead with the current master. Also, it seems we miss a padding or margin bottom when scrolling, because when we scroll inside the recipient panel, the last line is not aligned with the "To" line.

(In reply to Julien Wajsberg [:julienw] from comment #23) > Comment on attachment 8426142 [details] > Link to github > > I think you need to check with a newer master because your screenshots does > not take the composer refresh (landed last week) into account. > > As a result, it seems 3.7rem is very too big (it's about 2 lines), from my > investigations I think it should be 2.2rem instead with the current master. > > Also, it seems we miss a padding or margin bottom when scrolling, because > when we scroll inside the recipient panel, the last line is not aligned with > the "To" line. Thanks for reminder, the problem should be the list padding removed in the latest vr, so I made a little adjustment that having a margin for alignment.

Comment on attachment 8426142 [details] Link to github r=me Still there is a weird behavior: when there are enough recipients to make the recipient panel scrollable, when I swipe down the recipient panel, the recipient panel is scrolled up too. I wonder if we can prevent it from scrolling until it's open? Maybe having "overflow: hidden" by default, and "overflow: auto" when it's open (but in that case we may have issues when we call scrollIntoView on the last element...); or maybe GestureDetector should preventDefault when it finds a gesture? So if you have a great idea now, please do it and request another review, otherwise please file a follow-up...

In master:902b0cdfec14dd578080e1eb318872943e6dec80 Sorry I could not find a quick solution right away and it seems not apz issue either :-/ . But I have some discovery about the issue and I will note this on new created bug.