946519 - [B2G][SMS][MMS] Cropped MMS pictures from the message thread view cannot be opened by sender

Status: RESOLVED DUPLICATE of bug 944276

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

Description

[Brogan Zumwalt [Inactive]]

Description:
After sending an MMS picture message with a cropped image, the sender is unable to open sent picture by tapping it in message thread. Until Messages app is closed and reopened, attempting to open a sent MMS picture will show a black screen before crashing back to message thread.

Repro Steps:
1) Updated Buri Build ID: 20131204115608
2) Open Messages app
3) Tap compose icon to begin new message
4) Enter recipient information
5) Select paperclip icon to attach media
6) Press gallery
7) Tap existing image
8) Drag crop selection so that only rightmost portion of image is selected and press "Done"
9) Send message
10) Tap on thumbnail of picture just sent


Actual:
Cropped images sent by MMS cannot be opened by sender.

Expected:
Tapping on sent MMS image opens full image.

Environmental Variables
Device: Buri v 1.3 Mozilla RIL
Build ID: 20131204115608
Gecko: http://hg.mozilla.org/mozilla-central/rev/526e12792fc8
Gaia: 324c467fc6b202fd09efe4b16cd83960fd2901eb
Platform Version: 28.0a1
Firmware Version: V1.2_US_20131115


Notes:
Repro frequency: 3/3, 100%
See attached: video clip - http://youtu.be/hWsMjzO9Pus

Comment 1

[Jason Smith [:jsmith]]

Does this reproduce on 1.1 or 1.2?

Comment 2

[Julien Wajsberg [:julienw]]

FYI I don't reproduce on a Peak on current master/gaia

Comment 3

[Roland Kunkel [:RolandK]]

(In reply to Jason Smith [:jsmith] from comment #1)
> Does this reproduce on 1.1 or 1.2?

This does not reproduce on the v1.1 build for the Leo or Buri devices.

This does reproduces on the Buri v1.2 build.  

Environmental Variables:
Device: Buri v1.2 Com Ril
BuildID: 20131205004003
Gaia: 0659f16b9790b1cf9eba4d80743fcc774d2ffe3a
Gecko: af2c7ebb5967
Version: 26.0
RIL Version: 01.01.00.019.281
Firmware Version: V1.2_US_20131115

Comment 4

[Roland Kunkel [:RolandK]]

(In reply to rkunkel from comment #3)
> (In reply to Jason Smith [:jsmith] from comment #1)
> > Does this reproduce on 1.1 or 1.2?
> 
> This does not reproduce on the v1.1 build for the Leo or Buri devices.
> 
> This does reproduces on the Buri v1.2 build.  
> 
> Environmental Variables:
> Device: Buri v1.2 Com Ril
> BuildID: 20131205004003
> Gaia: 0659f16b9790b1cf9eba4d80743fcc774d2ffe3a
> Gecko: af2c7ebb5967
> Version: 26.0
> RIL Version: 01.01.00.019.281
> Firmware Version: V1.2_US_20131115

Sorry, forgot to include the environmental variables for the 1.1 build.

Buri v1.1 - Environmental Variables:
Device: (example: Buri v1.2 Mozilla RIL)
BuildID: 20131205041342
Gaia: 6ff3a607f873320d00cb036fa76117f6fadd010f
Gecko: 05117f42088f
Version: 18.0
Firmware Version: V1.2_US_20131115

Comment 5

[Jason Smith [:jsmith]]

This looks bad - looks like viewing a cropped image from a SMS thread isn't working in context. 

Two things:

1. Can you get a logcat?
2. Can you get a dmesg log?

Comment 6

[Julien Wajsberg [:julienw]]

Can I have a video as well, because I couldn't reproduce with the included STR ?

Thanks!

Comment 7

[Roland Kunkel [:RolandK]]

Attachment: logs archive

(In reply to Jason Smith [:jsmith] from comment #5)
> 1. Can you get a logcat?
> 2. Can you get a dmesg log?

Attaching logcat and dmesg logs.

Here is the kill message from the dmesg log:

<4>[  882.131919] select 461 (Usage), adj 10, size 5964, to kill
<4>[  882.131936] select 493 (Communications), adj 10, size 7322, to kill
<4>[  882.131951] send sigkill to 493 (Communications), adj 10, size 7322
<4>[  883.610413] select 461 (Usage), adj 10, size 5623, to kill
<4>[  883.610439] select 516 (Settings), adj 10, size 6788, to kill
<4>[  883.610456] send sigkill to 516 (Settings), adj 10, size 6788

Comment 8

[Jason Smith [:jsmith]]

Comment on attachment 8343852 [details]
logs archive

Going to attach the log files directly instead of archive...

Comment 9

[Jason Smith [:jsmith]]

Attachment: dmesg log

Comment 10

[Jason Smith [:jsmith]]

Attachment: Logcat

Comment 11

[Julien Wajsberg [:julienw]]

I'd still want a video of it's possible :) Thanks!

Comment 12

[Jason Smith [:jsmith]]

(In reply to Julien Wajsberg [:julienw] from comment #11)
> I'd still want a video of it's possible :) Thanks!

There's already a video included in comment 0. See http://youtu.be/hWsMjzO9Pus.

Comment 13

[Roland Kunkel [:RolandK]]

Attachment: Bug 946519 Video

(In reply to Julien Wajsberg [:julienw] from comment #6)
> Can I have a video as well, because I couldn't reproduce with the included
> STR ?


Attached video.

Comment 14

[Roland Kunkel [:RolandK]]

(In reply to Jason Smith [:jsmith] from comment #10)

The fist occurrence of this issue appears to be in the 12/5 build. This issue is not present in the 12/6 build, however it will repro in all builds after that.

- Last Working -
Environmental Variables:
Device: Buri v1.2 COM RIL
BuildID: 20131204004003
Gaia: 8d762f3376318fd6be390432db750ae4904c9ab6
Gecko: 758f3fb32dda
Version: 26.0
RIL Version: 01.02.00.019.102
Firmware Version:

- First Broken -
Environmental Variables:
Device: Buri v1.2 Com Ril
BuildID: 20131205004003
Gaia: 0659f16b9790b1cf9eba4d80743fcc774d2ffe3a
Gecko: af2c7ebb5967
Version: 26.0
RIL Version: 01.01.00.019.281
Firmware Version: V1.2_US_20131115

Comment 15

[Julien Wajsberg [:julienw]]

Kyle, could this be the same root cause than bug 944276?

Comment 16

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Doesn't seem like it.  This looks like an OOM.  Bug 944276 is an IPDL actor lifetime problem.

Comment 17

[Preeti Raghunath(:Preeti)]

QA,

Can we please confirm the patch that caused this regression?

Need a back out here.

Comment 18

[Jason Smith [:jsmith]]

Blocking+ for critical regression - will look into comment 17 as well.

I'm moving this to needsinfo rather than qawanted.

Comment 19

[Jason Smith [:jsmith]]

There are three commits in the Gaia regression range:

1. https://github.com/mozilla-b2g/gaia/commit/8d762f3376318fd6be390432db750ae4904c9ab6
2. https://github.com/mozilla-b2g/gaia/commit/1e33fd87d61de023b18961270e2f2abe2ead07c1
3. https://github.com/mozilla-b2g/gaia/commit/0659f16b9790b1cf9eba4d80743fcc774d2ffe3a

[3] is unrelated, as it's involving the Music app. [2] seems unrelated & unlikely as well. [1] is possible, as it touches on previewing images.

David - Could bug 935373 cause this regression?

Comment 20

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #19)
> There are three commits in the Gaia regression range:
> 
> 1.
> https://github.com/mozilla-b2g/gaia/commit/
> 8d762f3376318fd6be390432db750ae4904c9ab6
> 2.
> https://github.com/mozilla-b2g/gaia/commit/
> 1e33fd87d61de023b18961270e2f2abe2ead07c1
> 3.
> https://github.com/mozilla-b2g/gaia/commit/
> 0659f16b9790b1cf9eba4d80743fcc774d2ffe3a
> 
> [3] is unrelated, as it's involving the Music app. [2] seems unrelated &
> unlikely as well. [1] is possible, as it touches on previewing images.
> 
> David - Could bug 935373 cause this regression?

Bug # should be - bug 935273.

Comment 21

[Jason Smith [:jsmith]]

http://hg.mozilla.org/releases/mozilla-b2g26_v1_2/pushloghtml?fromchange=758f3fb32dda&tochange=af2c7ebb5967

Comment 22

[Jason Smith [:jsmith]]

This definitely has to be caused by bug 935273. Nothing else seems plausible in the regression range.

Comment 23

[Jason Smith [:jsmith]]

Talked with djf in IRC about this.

jsmith	djf: Context - bug 946519. The regression range seems to be pointing at your Gaia commit. Any ideas why?
djf	jsmith: looking
djf	jsmith: that is very weird. I can't think of any reason why that patch would have caused it. Are you sure this is a regression?
jsmith	djf: Looks like it. The regression range indicates this broke on 12/4/2013 on the 1.2 branch.
jsmith	by something that landed*
djf	jsmith: you can't back out that patch permanently because it fixed a blocker. But if backing it out fixes this bug, then please assign the bug to me (and send me an email?)
jsmith	djf: Right. Any chance you could look into bug anyways to see why this is happening?
djf	jsmith: the reason I'd like someone to confirm it was my patch is that that patch only affects the image pick part, and the failure is happening when viewing the image. So I kind of think it is more likely that this is graphics layer weirdness.
djf	jsmith: also, my Buri is pretty borked. I htink it needs a firmware update. I can't even see images when I attach them to a MMS message.
djf	So I'm unlikely to be able to reliably reproduce the bug since I don't have working hardware.
djf	jsmith: and as far as I know, getting new firmware for my Buri requires a window machine.
djf|afk	jsmith: I'm going to be afk for a couple of hours. Let's continue the discussion by email.

Comment 24

[Jason Smith [:jsmith]]

Note - I didn't really see any gfx related issues in the regression range.

Comment 25

[David Flanagan [:djf]]

Okay, looking at this at least. I misread the report and thought it was the receiver of the message that could not see the image, and that seemed completely unrelated to cropping on the sender.  I still don't understand how the changes to cropping could have caused this issue, however.

With a 1.2 build I can actually see images when I attach them to messages, so my Buri is not as broken as I feared.  However, it appears that I cannot send MMS messages.  Plain text works, but maybe my SIM card does not allow MMS messages for some reason?  Anyway, it sits there forever trying to deliver the MMS with the photo.  While it does that, viewing the photo works perfectly for me.  

So I'm not sure I'm going to be able to reproduce this.

Comment 26

[David Flanagan [:djf]]

One thing I notice from the attached video is that the image being sent is a screenshot that is then cropped. So it is quite small, and the MMS app does not need to resize it.  I wonder if there is a difference between big images that get resized and small images that are used as-is.

Comment 27

[David Flanagan [:djf]]

Ah ha!  I can reproduce this with a cropped screenshot as shown in the video, even though it never actually gets sent.

The other difference, of course, is that with screenshots it is a png image not a jpeg.

Comment 28

[David Flanagan [:djf]]

Okay, so a big jpeg, cropped or uncropped, but big enough to require a resized, works.
A small png, not reiszed does not work  

Is it the file size or the file type that causes the bug? Let's try the other cases:

A png image that is large enough to require resize (whether cropped or not) does not exhibit this bug.

A small png image that does not require resize does exhibit this bug if it is cropped, but does not if it is uncropped.

A small jpeg uncropped and and not resized does not exhibit the bug.

The same small jpeg cropped and not resized does exhibit the bug.

If I kill the sms app and restart, then viewing all of the images works.

So the bug does not seem related to png images.  

I do see two relevant pieces of information here:

 * the bug only occurs if the gallery app crops (resizes) the image and the MMS app does not resize it.

 * restarting the MMS app (and retreiving the images from persistant storage) makes the bug go away.

To me, these point to an in-memory blob issue.  Here's my thinking:

1) If the user does not crop the image, then the gallery app sends a file-backed blob to the MMS app.  If the user does crop the image, then the gallery app sends a memory-backed blob to the MMS app.  (I don't know whether the memory is shared by the gallery and MMS apps or whether a copy is made when the blob is transferred).

2) If the MMS app has to resize the image, it is somehow making its own independent copy of the image. I don't know if that copy is file backed or memory backed, but it the MMS app owns it.  If it does not have to resize, it is presumably using the blob it receives unmodified.

3) The MMS app also saves images somehow, and when restarted, reads them from persistant storage, getting a private copy.

It would be interesting to know (and I can't test since my sim card won't let me send MMS messages) if these small cropped images can actually be sent and received by other phones.  They are obviously saved successfully, so it is not like the blob is completely corrupt.  Maybe the issue only occurs when the blob from gallery is passed to MMS and then passed back to a new invocation of the gallery app to view it.

I've seen blob-and-activity issues like this two or three times before.  The workaround for the MMS app would be to always make a private copy of the image. Maybe by storing it to the DB and them immediately reading it back?  The long-term solution, however, is always to get Ben Turner involved.

Comment 29

[David Flanagan [:djf]]

Ben: I think blobs might be involved here.  Would you look at comment 28 and see what you think?

Jason: almost certainly not a gallery bug, so I'm setting the component back to SMS since that is where the symptom is exhibited.  (And if my reasoning in comment #28 is correct, where the workaround will have to be made.)

Comment 30

[David Flanagan [:djf]]

I actually think this is a dupe of bug 944276 and have not seen evidence of OOM.  And fortunately, bent is already thinking about 944276

Comment 31

[Jason Smith [:jsmith]]

(In reply to David Flanagan [:djf] from comment #30)
> I actually think this is a dupe of bug 944276 and have not seen evidence of
> OOM.  And fortunately, bent is already thinking about 944276

Yup, looks like it. That should have been koi+, not fugu+.