946995 - [Messages][Drafts] MMS Drafts don't restore correctly after app closes/restarts

Status: RESOLVED FIXED

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

Description

[Evelyn Eastmond [:evhan55]]

This is based on rwaldron/gaia/v1.3-drafts

STR:
1. Create a new thread, or open an existing thread
2. Start a draft message with MMS content
3. Click back. Choose 'save as draft'.
4. Force close Messages app
5. Open Messages app
6. Open the thread with the saved MMS content

Expected:
- Thread opens and content composer prefills with MMS content

Actual
- Thread opens and content composer is empty

Comment 1

[Julien Wajsberg [:julienw]]

This bug and bug 946996 probably share the same root, right? So let's dupe bug 946996 here, what do you think?

I'm adding bug 936648 as a dependency because I guess it's a follow-up to this bug.

Comment 2

[Evelyn Eastmond [:evhan55]]

(In reply to Julien Wajsberg [:julienw] from comment #1)
> This bug and bug 946996 probably share the same root, right? So let's dupe
> bug 946996 here, what do you think?
> 
> I'm adding bug 936648 as a dependency because I guess it's a follow-up to
> this bug.

Yes, probably.  I didnt want to presume anything since the cases were somewhat distinct.  (Loading texts from new/existing threads vs. loading MMS's only from existing threads).  I will dupe it anyway. Thank you.

Comment 4

[Evelyn Eastmond [:evhan55]]

Figured out what is causing the issue: onRenderMessage is being called the first time an existing thread is rendered, and it calls initializeRendering() which calls cleanFields() which clears the composer after the draft has been loaded...still working on finding a fix

Comment 5

[Rick Waldron [:rwaldron]]

(In reply to Evelyn Eastmond [:evhan55] from comment #4)
> Figured out what is causing the issue: onRenderMessage is being called the
> first time an existing thread is rendered, and it calls
> initializeRendering() which calls cleanFields() which clears the composer
> after the draft has been loaded...still working on finding a fix

Can we just move the code that does the population of the composer to be called after?

Comment 6

[Evelyn Eastmond [:evhan55]]

(In reply to Rick Waldron [:rwaldron] from comment #5)

> Can we just move the code that does the population of the composer to be
> called after?

Hmm, I will look

Comment 7

[Rick Waldron [:rwaldron]]

r=rwaldron

landed in v1.3-drafts https://github.com/rwaldron/gaia/commit/35a29711ddbdd431f725c9cdcc682baedc09cbe0

Comment 8

[Rick Waldron [:rwaldron]]

https://github.com/mozilla-b2g/gaia/commit/27f59ed55fc1fb8a1c1d9e1af1f9c4b4b7d4bbe1

Comment 9

[JeffJ]

This may be related, but in 1.2.0, if you are typing a message and accidentally hit the Home button instead of spacebar (dumping you back to the home screen), then hit the Message icon to go back to the app and continue editing, all your previous text repopulates in the edit screen. If you type additional text and then hit Send, only the original text sends. Everything added after going back to the app truncates, disappearing from the screen and does not show on the recipients phone either. Don't want to open another bug report, since this may have already been addressed, as I'm seeing it in 1.2.

Comment 10

[Rick Waldron [:rwaldron]]

(In reply to kb9yhv from comment #9)
> This may be related, but in 1.2.0, if you are typing a message and
> accidentally hit the Home button instead of spacebar (dumping you back to
> the home screen), then hit the Message icon to go back to the app and
> continue editing, all your previous text repopulates in the edit screen. If
> you type additional text and then hit Send, only the original text sends.
> Everything added after going back to the app truncates, disappearing from
> the screen and does not show on the recipients phone either. Don't want to
> open another bug report, since this may have already been addressed, as I'm
> seeing it in 1.2.

That's strange, there is no draft support in 1.2. Can you provide STR?

Comment 11

[Julien Wajsberg [:julienw]]

This is different and this is bug 939971. It _should_ be in v1.2 but maybe it was fixed too late to be in your 1.2 build (21st november).

Comment 12

[JeffJ]

Rick/Julien - Thanks. The behavior I saw was definitely as described in 939971. I apologize that I missed that in my search through the existing bugs. Wanted to make sure it had been addressed and it sounds like it's fixed. For the sake of completeness, I am using the Boot2Gecko 1.2.0.0-prerelease version supplied by ZTE for the Open, so that may be too old to have had the fix.

Comment 13

[Julien Wajsberg [:julienw]]

JeffJ, no problem, thanks a lot!