870416 - [MMS] Recipients container multiline view takes all available space

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::SMS, defect)

Description

[Borja Salguero [:borjasalguero]]

+ Height has a 'pull-down' effect while typing. CSS is not working as expected. (Issue 3 attachment)
+ Header is pushed up, so the layout of the app is broken
+ Height when dragging should take all the available space as in Page 19, Step 6 of WF

Comment 1

[Borja Salguero [:borjasalguero]]

Attachment: Snapshot of the height issue

Comment 2

[Borja Salguero [:borjasalguero]]

Attachment: Push app effect

Comment 3

[Mark Shiao]

Currently not seeing these issues in latest build.  Any additional build info?

Comment 4

[Dietrich Ayala (:dietrich)]

(In reply to Mark Shiao from comment #3)
> Currently not seeing these issues in latest build.  Any additional build
> info?

this bug is filed against a temporary branch where MMS work is landing until ready for gaia master.

Comment 5

[Rick Waldron [:rwaldron]]

This was completed with https://bugzilla.mozilla.org/show_bug.cgi?id=837994

Comment 6

[Rick Waldron [:rwaldron]]

Maybe someone that understands CSS better then I do should look at this. As far as I can tell setting min-height and letting the recipients box grow is insufficient because to avoid the "gap" between the previous recipients and the header, you must also change the value of "top" (from top: 1.2rem => top: -0.2rem)

Comment 7

[Rick Waldron [:rwaldron]]

This series of captures illustrates how far I was able to get, but I'm just spinning my wheels now. https://www.dropbox.com/sh/op52z1e2278rbhd/Ub0S-76SH9

https://github.com/rwldrn/gaia/compare/870416

Comment 8

[Rick Waldron [:rwaldron]]

References:

2 Recipients:
https://www.dropbox.com/sh/8jkb0osnvfda96e/TkcQuTbhHj#f:01.SMS.MMS_0004_Compose_2recipients.png

4 Recipients:
https://www.dropbox.com/sh/8jkb0osnvfda96e/TkcQuTbhHj#f:01.SMS.MMS_0005_Compose_4recipients.png

Comment 9

[Kevin Grandon :kgrandon]

Attachment: Github pull request pointer

Working on this. This patch addresses a bunch of the focus issues that I was seeing.

Comment 10

[Kevin Grandon :kgrandon]

Comment on attachment 751145 [details]
Github pull request pointer

Hi Corey - Could you give this one an initial review? 

I fixed several focus issues that I saw, and I think that the height handling should be a bit better. Please take a look and let me know what you think.

Comment 11

[Corey Frang [:gnarf]]

Comment on attachment 751145 [details]
Github pull request pointer

I like where it's going - though I would really prefer to avoid binding a event listener on window.  Will focusout work?

Comment 12

[Kevin Grandon :kgrandon]

Can you be more specific about why binding a listener on window is bad? This is pretty common practice for event delegation.

I would love to use focusout, but it looks like it's not supported yet, bug 687787 has more details.

Comment 13

[Rick Waldron [:rwaldron]]

It's not common to bind event to the window for event delegation. It's common to bind a single event to a container node within the document and delegate handling based on child node targets.

Eiter way, this issue was resolved in https://github.com/mozilla-b2g/gaia/commit/54118408dacaedf4b06c393d5b9a500450c5e7f2 and this bug was supposed to be closed as a duplicate of bug 870544

Comment 14

[Kevin Grandon :kgrandon]

Sounds good. There seems to still be a lot of remaining expand/collapse issues for me though. I will look through and file new bugs for the ones that don't exist.

Comment 15

[Rick Waldron [:rwaldron]]

The expand/collapse behaviours are matched to the current v8.0 spec

Comment 16

[Victoria Gerchinhoren [:vicky]]

I still reproduce this bug, the recipients field is taking just a portion of the available space to show the recipients.

Comment 17

[Dietrich Ayala (:dietrich)]

Victoria, can you better describe what the problem is on the latest build? And a screenshot? We discussed, and are not clear on it. Thanks!

Comment 18

[Borja Salguero [:borjasalguero]]

I think that the scenario is the following:
- Add a lot of recipients in 'new' screen of MMS/SMS App
- Tap on 'back' and cancel the SMS
- Go again to 'new'

EXPECTED:
Recipients container height is reset, so the form is started from the scratch

CURRENTLY:
Recipients container height is the previous one, so the layout is broken.

Comment 19

[Victoria Gerchinhoren [:vicky]]

The problem Borja is commenting is a different thing than what I am describing, and I filed a bug for this issue Borja mentions: https://bugzilla.mozilla.org/show_bug.cgi?id=877615

But my concern has to do with the behaviour of the recipients field when pulled down, right now it does not expand all the way down to the input field as I understand it should, and also when the keyboard is dismissed, this recipients field should expand as much as needed taking advantage of the large space available in the screen.

But for further clarification on this I am pinging Ayman to comment.

Comment 20

[Victoria Gerchinhoren [:vicky]]

The problem Borja is commenting is a different thing than what I am describing, and I filed a bug for this issue Borja mentions: https://bugzilla.mozilla.org/show_bug.cgi?id=877615

But my concern has to do with the behaviour of the recipients field when pulled down, right now it does not expand all the way down to the input field as I understand it should, and also when the keyboard is dismissed, this recipients field should expand as much as needed taking advantage of the large space available in the screen.

But for further clarification on this I am pinging Ayman to comment.

Comment 21

[Victoria Gerchinhoren [:vicky]]

Attachment: shows the size of the recipients field when keyboard is dismissed

Comment 22

[Victoria Gerchinhoren [:vicky]]

Attachment: shows the size of the recipients field when keyboard is displayed

Comment 23

[ayman maat :maat]

hi guys

I think Victoria's attachments capture the bug nicely.

wireframe pack HTML5_SMS-MMSUserStorySpecifications_20130503_V8.0
page 19

We need to give maximum visibility to the content of the 'To' field to reduce cognitive loading. Therefore it was specified that the 'To' field should be able to be pulled downwards until its bottom edge is level with the top edge of the send button. At this point it will scroll within its own area. this should happen when the keyboard is open. looking at attachment 755883 [details] we are not currently expanding the 'To' field as far as the top edge of the send button.

It would be ideal if expansion of the To field as far as the top edge of the send button could also happen when the keyboard is closed (though keyboard closed in new message mode is not illustrated in the wireframes).

Let me know if you need any more input

Comment 24

[Dietrich Ayala (:dietrich)]

Been a long time, no action, and no critical user impact, so not going to hold the entire release on this. If we can get a patch once we fix the other higher-priority bugs, we should totally fix this. Otherwise, let's fix it in 1.2!

Comment 25

[Kevin Grandon :kgrandon]

I'll take a look if I free up - otherwise un-assigning in case someone wants to grab this.

Comment 26

[Rick Waldron [:rwaldron]]

Remaining issues were addressed in different bugs, I can't find all of them.

https://bugzilla.mozilla.org/show_bug.cgi?id=877590

Comment 27

[Borja Salguero [:borjasalguero]]

Please read the comment https://bugzilla.mozilla.org/show_bug.cgi?id=870416#c16. It's easy to reproduce

Comment 28

[Rick Waldron [:rwaldron]]

Updated the title to more accurately reflect the remaining issue https://bugzilla.mozilla.org/show_bug.cgi?id=870416#c16

Comment 29

[Rick Waldron [:rwaldron]]

Attachment: Github Pull Request https://github.com/mozilla-b2g/gaia/pull/10513

Comment 30

[Rick Waldron [:rwaldron]]

Dietrich, this can/should be restored to leo+

Comment 31

[Rick Waldron [:rwaldron]]

Dietrich, further information...

- still part of the UX spec
- was previously leo+
- leo- due to no activity
- now ready to be leo+ again

Comment 32

[Wayne Chang [:wchang]]

Triage - leo+ to follow spec

Comment 33

[Corey Frang [:gnarf]]

Comment on attachment 765914 [details] [review]
Github Pull Request https://github.com/mozilla-b2g/gaia/pull/10513

r=me - One non-blocking suggestion left

Comment 34

[Borja Salguero [:borjasalguero]]

Comment on attachment 765914 [details] [review]
Github Pull Request https://github.com/mozilla-b2g/gaia/pull/10513

Hi Rick. I would like to ensure as well that the behaviour is the expected, because I have seen nothing related with 'touch' events in the could, and we should have it for handling this (currently all actions are based on 'click', and this is not the right behavior). Let me take a look and I will try to help with this ok? Thanks!

Comment 35

[Corey Frang [:gnarf]]

master: https://github.com/mozilla-b2g/gaia/commit/bebbeefa1ddf854b537c50f27a924e76dabc574d

Comment 36

[John Ford [:jhford] CET/CEST Berlin Time]

Uplifted bebbeefa1ddf854b537c50f27a924e76dabc574d to:
v1-train: ba334ceba63254e0576b05a217f910565e2bb850

Comment 37

[John Ford [:jhford] CET/CEST Berlin Time]

v1.1.0hd: ba334ceba63254e0576b05a217f910565e2bb850

Comment 38

[sbogati]

Issue Do not reorudeces on Leo 
Environmental  Variables:
Build ID: 20130805071207
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/a2a9b89ef5ee
Gaia: 45f6a739b09292e16717fb21003386c914ca29c2
Recipients container height is reset,so the form is started from the scratch