968714 - [Messages] The "maximum size is reached" notice disappear too quickly

Status: RESOLVED WONTFIX

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

Description

[Julien Wajsberg [:julienw]]

STR:
* open the Music app
* select a big Music song
* press the share button
* press Messages item

Expected:
* a "Maximum size is reached" notice is displayed and stayed on screen

Actual:
* this notice is displayed but disappears too quickly.

This change comes from bug 952109 where we wanted to make the _subject_ max length notice disappear, but not the _message_ max length notice.

To be clear, there are 2 issues here IMO:
* the time we display the subject max length notice is too short (2 seconds), I barely have the time to read the text
* the 'message max length notice" should not disappear

Ayman, I'd like to know your advice here before moving forward. Also, note that bug 952109 is on 1.3, so please also give your advice whether this bug should be blocking 1.3.

Comment 1

[Julien Wajsberg [:julienw]]

Attachment: Video reproducing the STR

Comment 2

[ayman maat :maat]

Thanks loads for the Video Julien

I agree that the message appears too quickly to be comprehended …However I think there is a much bigger issue here. Its not clear to me why the message ‘You’ve exceeded the maximum length. Remove special characters or shorten the message to send it’ is generated after an attachment is added to the message. My understanding is that these ‘maximum length’ messages were only generated when the *text* within the message reached the maximum length for the message. 

In the scenario you describe and illustrate with the video as far as i am aware only one of two things should happen. Either:

1) the attachment should fail to be added on the grounds that there is not enough space in the message to add it and referring back to wireframe pack HTML5_SMS-MMSUserStorySpecifications_20130503_V8.0 page 34 a ‘file too large’ dialogue should be presented to the user informing them of the situation. or, 

2) the attachment is added to the message. 

In either of these cases no ‘maximum length’ message should be presented.

If this is not the case and for some reason this message is generated for valid reasons I would propose that the text within it is clearly wrong as direction to recover from the issue by ‘shortening of message’ implies reduction of text, and in your video the message has no text.

At this moment I am of the opinion that this is the wrong message being presented and we are looking at a regression. ni? to Julien, whats your thoughts?

Comment 3

[Julien Wajsberg [:julienw]]

Actually we already have bug 943976 to cover this. We didn't block on it because it was like this since 1.1 already.

We can actually just fix bug 943976 and let go this message. It will be difficult to justify to block on it although if we fix it quickly we could probably still request an approval.

Comment 4

[ayman maat :maat]

(In reply to Julien Wajsberg [:julienw] from comment #3)
> Actually we already have bug 943976 to cover this. We didn't block on it
> because it was like this since 1.1 already.
> 
> We can actually just fix bug 943976 and let go this message. It will be
> difficult to justify to block on it although if we fix it quickly we could
> probably still request an approval.

oh, i would have absolutely blocked 943976 back in the day as the message is not only a complete misrepresentation but it makes absolutely no sense to the user and on top of all that is very easy to generate, so certainly cannot be filed in the 'edge case' bucket. 

Anyway like you say lets try and get this fixed quickly and request approval.

However i have an outstanding question. in relation to this: In the valid scenario whereby the user reaches the maximum (text) length of a message... do we still have this message appearing too quickly situation? (this is actually what i was trying to reproduce when I was crashing the app and why i pinged you over IRC - i cannot repro this behaviour to check) ni? to julien

Comment 5

[Julien Wajsberg [:julienw]]

Thinking a little more here, I think the notice is not displaying enough because there is the whole transition happening and taking a lot of time, probably eating the 2 seconds delay.

(In reply to ayman maat :maat from comment #4)
> (In reply to Julien Wajsberg [:julienw] from comment #3)
> However i have an outstanding question. in relation to this: In the valid
> scenario whereby the user reaches the maximum (text) length of a message...
> do we still have this message appearing too quickly situation? (this is
> actually what i was trying to reproduce when I was crashing the app and why
> i pinged you over IRC - i cannot repro this behaviour to check) ni? to julien

We can't really reach the max text length now, as we're converting to MMS. The MMS conversion notice is displaying long enough IMO.

I'm duping to Bug 943976, let's fix that one quickly, as a patch is already ready there.

Comment 6

[ayman maat :maat]

(In reply to Julien Wajsberg [:julienw] from comment #5)
> Thinking a little more here, I think the notice is not displaying enough
> because there is the whole transition happening and taking a lot of time,
> probably eating the 2 seconds delay.
> 
> We can't really reach the max text length now, as we're converting to MMS.
> The MMS conversion notice is displaying long enough IMO.
> 

Well we can reach max text length because we need to remember that not all SIMs will support MMS. I think SMS has a character limit is about 1035 characters (or less if special characters are used) so the character limit does exist and we need to clearly inform the user what is going on when they reach it. In view of that the period of time the ‘You’ve exceeded the maximum length. Remove special characters or shorten the message to send it’ needs to be addressed and i don't think 943976 will do thia

Comment 7

[Julien Wajsberg [:julienw]]

Discussed over IRC:

* we can't reach max text length currently, because we switch to MMS automatically
* _but_ we will change this eventually and so we need to fix this bug.

So reopening.

Comment 9

[Julien Wajsberg [:julienw]]

Bug 943976 didn't make it to 1.3 (and probably not 1.4 either) so let's fix this instead. Should be a one line fix so I'm nominating it. See also the dupe bug 975294.

Comment 10

[Preeti Raghunath(:Preeti)]

What is the user impact of the fix?

Comment 11

[Jason Smith [:jsmith]]

(In reply to Preeti Raghunath(:Preeti) from comment #10)
> What is the user impact of the fix?

Not possible to read an error message, so the user isn't fully aware that an error has been hit when too large of a file is attached to a MMS message.

Comment 12

[Maria Angeles Oteo (:oteo)]

I think we have two issues here:

1.The content of the message is not correct because we are saying to the user "You've exceeded the maximum length. Remove special characters or shorten the message to send it", and it's not correct because the problem is that the attached song is too big so it can be confusing for the user.

Besides, when trying to send that same big song from the SMS composer, not the music application, the text shown is "The file you have selected is too large", which is the correct one.

2.The message appears too quickly to be comprehended.

Not sure, Julien, what issue you want to fix in this bug, 1, 2 or both?

Just F.Y.I, I've just realized that the incorrect message appears whenever you click on the "to" input, so for me the issue 1(incorrect message) would be the more critical to fix

Comment 13

[Preeti Raghunath(:Preeti)]

Moving to backlog as recovery path exists.

Comment 14

[Julien Wajsberg [:julienw]]

(In reply to Maria Angeles Oteo (:oteo) from comment #12)
> I think we have two issues here:
> 
> 1.The content of the message is not correct because we are saying to the
> user "You've exceeded the maximum length. Remove special characters or
> shorten the message to send it", and it's not correct because the problem is
> that the attached song is too big so it can be confusing for the user.
> 
> Besides, when trying to send that same big song from the SMS composer, not
> the music application, the text shown is "The file you have selected is too
> large", which is the correct one.

Yep, we don't have the same codepath, this is sad. (Bug 943976, see comment 5).

> 
> 2.The message appears too quickly to be comprehended.
> 
> Not sure, Julien, what issue you want to fix in this bug, 1, 2 or both?

The second one only.


Borja, would you have a look here? Are the 3 seconds "swallowed" by the animation+reflow?

Comment 15

[Borja Salguero [:borjasalguero]]

I'll take a look to this bug!

Comment 16

[Francesco Lodolo [:flod]]

Removing l12y keyword, since it doesn't seem to be a localizability issue. If I missed something, feel free to shout at me and restore the value.

Comment 17

[Julien Wajsberg [:julienw]]

Francesco: you're right, it's not.

Comment 18

[ankit93040]

These issue can be now closed because patch for bugzilla 943976 will remove these.

In detail about patch for bugzilla 943976:-

1. If we share a (video/image/music) from any application to Message & if its size is > 300Kb then it won't be shared instead it will give an alert saying "The file is too large & cannot be appended".

2. If we try to attach a (video/image/music) from Message app & if the size is > 300Kb then it won't be appended instead it will give an alert saying "The file is too large & cannot be appended".

So, these bug no more makes sense.

Comment 19

[Julien Wajsberg [:julienw]]

See comment 6, this still makes sense for no-MMS scenario (that we don't support yet).

Comment 20

[ankit93040]

Hi Julien

I tried to reproduce the bug - only way to reproduce this bug is by making the compose.size > 300Kb which can be only be done by appending an attachment at last (I discuss these below why attachment at last).

What I mean is this:- 

Pre-Condition: Suppose we have a message with size 299Kb (Combination of texts & pics/*)

Now we have two options to make its size > 300Kb :- Either by typing more characters or by appending an image/*.

Case 1:- We go only with typing characters - Then as soon as it crosses 300Kb we get a popup message saying - "You've reached the maximum length" & after that we can't type any more characters. So, these is not applicable for these bug.

Case 2:- We go with attaching pics/* - As soon as we add a 1Kb more it is appended to the message. While appending to the compose message - 
   a>. It displays "You've exceeded the maximum size. Remove attachments or shorten the message to send it" - which is there for very little time (1 sec @ while appending). 
   b>. After appending the image/* - When we tap on the TO FIELD again we get the message "You've exceeded the maximum size. Remove attachments or shorten the message to send it" which persists for 3 sec.

These is why I said that these can only be reproduced by appending an Attachment at last.

Now my question is these - 

Do we need to increase the time for No.a or No.b or both?

I think it is for No.a only.

Kindly share your view on what needs to be done.

thanks!

Comment 21

[Julien Wajsberg [:julienw]]

(In reply to ankit93040 from comment #20)

> These is why I said that these can only be reproduced by appending an
> Attachment at last.

What I meant is that in some countries we could be in a situation where MMS don't work. For example, for me MMS doesn't work when I'm roaming. The Messages app doesn't support this now but it might support this later, actually preventing switching to MMS if we exceed the max size for a SMS.

> 
> Now my question is these - 
> 
> Do we need to increase the time for No.a or No.b or both?
> 
> I think it is for No.a only.

Ideally it should be for a. only but I don't know if that's possible. Do you know why the timeout for a. is smaller? Is it because of the animation? Or is it because we remove the notification when we enter the composer?

Comment 22

[ankit93040]

Hi Julien

Even I am not so much clear about it (Comment # 20).

I propose a little change in implementation here - Currently we show the message "You've exceeded the maximum size. Remove attachments or shorten the message to send it" appended to "Resizing the attached image" while appending to message.

What I propose is theses - we don't show these message "You've exceeded the maximum size. Remove attachments or shorten the message to send it" at all, while appending. Once the "Resizing the attached image" is over then we will show the message "You've exceeded the maximum size. Remove attachments or shorten the message to send it".

What's your views?

Comment 23

[Julien Wajsberg [:julienw]]

But you'll have the issue again if you attach a video instead of an image.

I'm keeping the needinfo to dig a little more into the issue.

Comment 24

[Julien Wajsberg [:julienw]]

ok, the issue is that we show the notice first when we add the content, but then we hide it in updateCounterForSms, that is started after a delay in updateCounter.

Now that we have bug 943976 and once we'll have bug 936729, I don't think we'll be able to trigger this issue anymore. Therefore I agree with you to close this bug.

We'll file another bug in the future if necessary.