971805 - [B2G][SMS][MMS] Cropping an image from gallery so that more than half the image remains does not attach to MMS in messages app

Status: RESOLVED INVALID

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

Description

[Brogan Zumwalt [Inactive]]

Description:
In Messages app while attaching an image from the gallery, cropping selected image so that more than half the image remains results in the picture not being attached to MMS after pressing "done". This occurs while cropping on either the horizontal or vertical axis.

Repro Steps:
Prerequisite: Have images in gallery taken with phone camera
1) Updated Buri to BuildID: 20140212004003
2) Open Messages app
3) Tap compose new message icon in top right
4) Press attach icon in top right
5) Choose "Gallery"
6) Select image taken with phone camera
7) Crop right of image slightly (e.g. < 80%)
8) Tap "Done"

Actual:
Cropping image so that more than half of image remains does not attach to MMS.

Expected:
All cropped images properly attach to MMS.

Environmental Variables:
Device: Buri v1.3 Mozilla RIL
BuildID: 20140212004003
Gaia: ce17d5eae7b1893ae4397c814b10ae598fcbdb58
Gecko: ab07e61c2eb0
Version: 28.0
Firmware Version: V1.2-device.cfg

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

Comment 1

[Julien Wajsberg [:julienw]]

ooook

Could bug 966320 regress this?

Comment 2

[Julien Wajsberg [:julienw]]

Brogan, a logcat could help as well!

Comment 3

[Brogan Zumwalt [Inactive]]

Attachment: Logcat

Attached logcat

Comment 4

[Brogan Zumwalt [Inactive]]

Issue also occurs on 1.4

Result:
Cropping image so that more than half of image remains does not attach to MMS.

Environmental Variables:
Device: Buri v1.4 Master Mozilla RIL
BuildID: 20140212040203
Gaia: 4c6b5142d3b716f1c4ea502eeb92d3119f2b01c6
Gecko: 802d87c77e76
Version: 30.0a1
Firmware Version: V1.2-device.cfg

Comment 5

[gbennett]

Unable to repro on latest 1.2
Environmental Variables:
Device: Buri 1.2 COM
BuildID: 20140210004002
Gaia: 539a25e1887b902b8b25038c547048e691bd97f6
Gecko: 2673f348598c
Version: 26.0
RIL Version: 01.02.00.019.102
Firmware Version: v1.2-device.cfg

This repros on the first stable 1.3 build.
Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20130919040201
Gaia: 0dedb5b3789afc638a0c7c67652937fcb30e77d2
Gecko: 803189f35921
Version: 27.0a1
Firmware Version: v1.2-device.cfg

Comment 6

[Julien Wajsberg [:julienw]]

taking to investigate

Comment 7

[Kai-Chih Hu [:khu]]

(In reply to Julien Wajsberg [:julienw] from comment #6)
> taking to investigate

Thank you, Julien!!

Comment 8

[David Scravaglieri [:scravag]]

triage waiting for julien feedback

Comment 9

[Julien Wajsberg [:julienw]]

I reproduced it on Buri and it's a crash from Gallery. Note that I can't reproduce on Peak.

I don't know why we don't see the crash toaster information in the video but I definitely had it.

Crash is at [1], don't know if that's useful at all because it does not have my symbols. Still this seems to point to bug 970403.

[1] https://crash-stats.mozilla.com/report/index/0cf373e3-4507-4da9-8bcd-c28822140213

I'll try to run gdb to catch the stack trace.

Comment 10

[Julien Wajsberg [:julienw]]

Funny enough, when I trace using gdb, it crashes before cropping, when it tries to display it.

Ok, this is now out of my skills, but I'm requesting a regression window so that it moves forward.

Comment 11

[Jason Smith [:jsmith]]

There's already a window here.

Comment 12

[Julien Wajsberg [:julienw]]

That's right, but it's not very actionable. Is it somehow possible to have a regression for central only ?

Plus I highly doubt it was not working at all since december...

Comment 13

[Julien Wajsberg [:julienw]]

I meant "september".

Comment 14

[Jason Smith [:jsmith]]

(In reply to Julien Wajsberg [:julienw] from comment #12)
> That's right, but it's not very actionable. Is it somehow possible to have a
> regression for central only ?
> 
> Plus I highly doubt it was not working at all since december...

It's probable we can have regressions that only reproduce on a earliest build for a target branch & later. What that means is that something is fundamentally different on the latest 1.2 branch vs. earliest 1.3 branch, which causes the bug to reproduce on 1.3, but not 1.2.

Comment 15

[Julien Wajsberg [:julienw]]

If i'm not wrong, the earliest 1.3 build is the build from central just after the 1.2 branching. So I'd say nothing would be fundamentally different.

I think that means something was fixed between the 1.2 branching and the latest 1.2 builds. So I guess we can try to find a (reverse) regression window there. I agree that we won't find anything on central (or it would be earlier than that).

Do you think it would make sense to try to find the fixing commit on 1.2? Because the current regression window is useless.

Comment 16

[Jason Smith [:jsmith]]

(In reply to Julien Wajsberg [:julienw] from comment #15)
> If i'm not wrong, the earliest 1.3 build is the build from central just
> after the 1.2 branching. So I'd say nothing would be fundamentally different.
> 
> I think that means something was fixed between the 1.2 branching and the
> latest 1.2 builds. So I guess we can try to find a (reverse) regression
> window there. I agree that we won't find anything on central (or it would be
> earlier than that).
> 
> Do you think it would make sense to try to find the fixing commit on 1.2?
> Because the current regression window is useless.

Yeah - we could do a reverse regression window on 1.2. Let's find out what that is.

Comment 17

[gbennett]

Checking on two different devices and over fifteen builds I was not able to find a build that repro'd this issue. I'm going to leave on the regressionwindow-wanted, but take off myself from QA contact as someone might be able to figure it out on Tuesday if you want.

Comment 18

[Jason Smith [:jsmith]]

(In reply to gbennett from comment #17)
> Checking on two different devices and over fifteen builds I was not able to
> find a build that repro'd this issue. I'm going to leave on the
> regressionwindow-wanted, but take off myself from QA contact as someone
> might be able to figure it out on Tuesday if you want.

Does this reproduce on the last 1.2 master build before we branched?

Comment 19

[Matthew Vaughan]

This issue does not reproduce on the 09/16 or 09/17 1.2 builds for me.

Comment 20

[Brogan Zumwalt [Inactive]]

This issue also appears in the latest 1.4 master build when adding a slightly cropped image to a new contact in the Contacts app. Should a new bug be filed, or should this be considered part of the same bug?

Comment 21

[Julien Wajsberg [:julienw]]

This is probably the same bug but nobody reproduces this except you :(

Brogan, could you by chance do the reverse regression window as asked in comment 16?

Comment 22

[Jason Smith [:jsmith]]

Re-adding regressionwindow-wanted to get that reverse regression window on 1.2.

Comment 23

[Matthew Vaughan]

(In reply to Matthew Vaughan from comment #19)
> This issue does not reproduce on the 09/16 or 09/17 1.2 builds for me.

Unfortunately I was incorrect about this occurring on the last 1.2 master build because I was cropping too much of the image. This issue DOES reproduce on the 09/17 1.2 build, and the 09/16 1.2 build crashes (looks like an OS crash) when attempting to reproduce this issue. 

I tested this on the first 1.2 build from 06/21/13 and found that just cropping the sides of an image in general seems to cause problems. It will attach the image, but the preview for it will be a placeholder image and will crash the Message app if you tap on it and click "View".

It seems that the cropping threshold to reproduce this issue can be different between builds, some requiring the image to only be cropped a very small amount, or the STR may need to be repeated once. With that said, this issue does reproduce for me on the 02/20/14 1.2 build. I tested several older 1.2 builds and am able to reproduce this issue on all of them.

This issue does *not* reproduce on the 02/18/14 1.1 build.

Comment 24

[Matthew Vaughan]

Jason, 

Based off of the information from comment 23, what would you like us to do with this bug?

Comment 25

[Jason Smith [:jsmith]]

(In reply to Matthew Vaughan from comment #23)
> (In reply to Matthew Vaughan from comment #19)
> > This issue does not reproduce on the 09/16 or 09/17 1.2 builds for me.
> 
> Unfortunately I was incorrect about this occurring on the last 1.2 master
> build because I was cropping too much of the image. This issue DOES
> reproduce on the 09/17 1.2 build, and the 09/16 1.2 build crashes (looks
> like an OS crash) when attempting to reproduce this issue. 
> 
> I tested this on the first 1.2 build from 06/21/13 and found that just
> cropping the sides of an image in general seems to cause problems. It will
> attach the image, but the preview for it will be a placeholder image and
> will crash the Message app if you tap on it and click "View".
> 
> It seems that the cropping threshold to reproduce this issue can be
> different between builds, some requiring the image to only be cropped a very
> small amount, or the STR may need to be repeated once. With that said, this
> issue does reproduce for me on the 02/20/14 1.2 build. I tested several
> older 1.2 builds and am able to reproduce this issue on all of them.
> 
> This issue does *not* reproduce on the 02/18/14 1.1 build.

I think this is off in left field - this isn't following the STR in the bug as filed. Please retest following the STR in the bug.

Comment 26

[Matthew Vaughan]

(In reply to Jason Smith [:jsmith] from comment #25)
> I think this is off in left field - this isn't following the STR in the bug
> as filed. Please retest following the STR in the bug.

When I follow the STR, I'm able to reproduce this issue in 1.2. The only difference between 1.2 and 1.3, in regards to reproducing the issue, is how much of the image I have to crop before OK'ing the image to be attached. In 1.2, I have to crop a very small amount (maybe ~1-5%) of the image. If I crop much more, the issue won't reproduce. In 1.3, I can crop ~15% of the image and still reproduce the issue.

I spoke with the reporter to make sure I was running through the STR correctly since step 7 may be a little unclear. In that step, he really meant to say to crop less than 20% of the image, therefore leaving 80% or more of the original image intact. 

I hope this is helpful. :)

Comment 27

[Punam Dahiya [:pdahiya]]

Tested multiple times and not able to replicate the issue in below environment

BuildID: 20140220004003
Gaia: a43904d9646109b48836d62f7aa51e499fbf4b2e
Gecko: 7c32fd60a04a2f7e47aef152de6729401a9d4b1e
Version: 1.3
Device:  Hamachi


I did see a crash in 1.4, but was able to successfully crop and attach image to a message in today's 1.3 hamachi-eng build. 
Attaching the video and log cat. One difference noticed in today's 1.3 build log cat vs attached in comment #3 

Logcat from Latest 1.3 hamachi- eng build
02-20 18:43:26.969 E/memalloc(  140): /dev/pmem: No more pmem available
02-20 18:43:26.969 E/msm7627a.gralloc(  140): gralloc failed err=Out of memory

Logcat from Comment#3
02-12 09:53:27.839: I/Gecko(546): SharedSurface_Gralloc::Create -------
02-12 09:53:27.839: E/memalloc(136): /dev/pmem: No more pmem available
02-12 09:53:27.839: W/memalloc(136): Falling back to ashmem


Julien, the crash seen by you in comment #9 is in 1.4 (based on crash-stats), are you able to see the crash in 1.3? Also, is the above logcat difference expected. I am not a memory expert and will appreciate your inputs. Thanks

Comment 28

[Punam Dahiya [:pdahiya]]

Attachment: Hamachi - 1.3-eng -20140220-build - logcat

Link to video http://youtu.be/d1Be0veut2Y

Comment 29

[Jason Smith [:jsmith]]

On the basis of saving everyone's sanity, I'm going to close this bug out.

Reporter - Can you refile the bug here that actually focuses on what the bug is? I need a clear understanding of what the problem is given the information discussed in these comments.

Comment 30

[Julien Wajsberg [:julienw]]

(In reply to Punam Dahiya from comment #27)
> 
> Julien, the crash seen by you in comment #9 is in 1.4 (based on
> crash-stats), are you able to see the crash in 1.3?

I haven't tried...

> Also, is the above
> logcat difference expected. I am not a memory expert and will appreciate
> your inputs. Thanks

I'm not either ;) but someone from the graphics team (eg :milan) will help you here.

Comment 31

[Brogan Zumwalt [Inactive]]

Follow up bug filed Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=975599