946439 - [B2G][SMS] Replacing a video attached to a SMS with one that is too large causes the menu to overlap the new message

Status: RESOLVED WORKSFORME

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

Description

[KTucker [:KTucker][Inactive 3/4/2016]]

Attachment: 2013-12-04-13-22-22.png

Description:
Replacing a video attached to a SMS with one that is too large causes the "Replace video" menu text to overlap the new message because the overlay will be missing. It does fix itself after a few seconds though. This occurs if the user has a large amount of messages on their phone.

Repro Steps:
1)  Updated Buri to Build ID: 20131204004003
2)  Ensure the test phone device has a mixture of 2000 SMS and MMS messages on it. 
3)  Tap on the "Video" icon.
4)  Tap on a video that is small in size.
5)  Tap on the "Share" button.
6)  Tap on "Messages".
7)  Long touch on the attached video in the SMS.
8)  Tap on "Replace video".
9)  Tap on "Video".
10)  Tap on a video that is over 500 KB.
11) Tap on the "Check mark" in the upper right corner of the screen to select it.
12) When prompted "The file you have selected is too large", tap on the "OK" button.
13) Tap on the "Home" button on the phone. 
14) Tap on the "Messages" icon and observe the screen.

Actual:
The "Replace video" menu text overlaps the "New message" screen because the overlay will be missing for a few seconds.

Expected:
No overlapping occurs and the "Replace video" appears normal.

Environmental Variables
Device: Buri v 1.2.0 COM RIL
Build ID: 20131204004003
Gecko: http://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/758f3fb32dda
Gaia: 8d762f3376318fd6be390432db750ae4904c9ab6
Platform Version: 26.0
RIL Version: 01.02.00.019.102 

Notes:
Repro frequency: 100%
See attached: screenshot, logcat

Comment 1

[KTucker [:KTucker][Inactive 3/4/2016]]

This issue does not occur on Leo v 1.1.0 COM RIL 

nvironmental Variables
Device: Leo v 1.1.0 COM RIL
Build ID: 20131024041202
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/e4cb5a852e3d
Gaia: 39b0203fa9809052c8c4d4332fef03bbaf0426fc
Platform Version: 18.1
RIL Version: 01.01.00.019.264 

The user can only share videos through the video app via bluetooth.

Comment 2

[Jason Smith [:jsmith]]

Sounds like a perf regression - overlay is taking too long to load.

Comment 3

[Julien Wajsberg [:julienw]]

It's not a regression, I've always seen it to some extent. The issue is that the Building Blocks does not use a background-color and the device takes some time to get the background image.

The fix is easy: add a background-color to the action menu BB.

Comment 4

[sarsenyev]

Attachment: 2013-12-04-17-02-57.png

I noticed on working builds the keyboard doesn't pop up during the file converting process in a MMS attachment, on broken builds the keyboard pops up during the converting process (see the screenshot attachment)

The regression window for this issue:

The last working build:
Device: Buri 1.2 Moz RIL build
BuildID: 20131031004003
Gaia: df049e3177ced0ca493ff0d192c65f18392bb462
Gecko: 93eafd042c1c
Version: 26.0
Firmware version: v1.2_2013115

The build when the bug is started to occur:
Device: Buri 1.2 Moz RIL build
BuildID: 20131101004000
Gaia: e717aec947571f5daf923c040a82f9f0719bb526
Gecko: 54de309e18a9
Version: 26.0
Firmware version: v1.2_2013115

Comment 5

[sarsenyev]

Attachment: 2013-12-04-17-08-29.png

Comment 6

[Jason Smith [:jsmith]]

(In reply to Julien Wajsberg [:julienw] from comment #3)
> It's not a regression, I've always seen it to some extent. The issue is that
> the Building Blocks does not use a background-color and the device takes
> some time to get the background image.
> 
> The fix is easy: add a background-color to the action menu BB.

Then why is there a confirmed regression window in comment 4?

Anyways - I don't think this is a blocker - it's a edge case + minor visual glitch.

Comment 7

[José Vittone]

(In reply to Julien Wajsberg [:julienw] from comment #3)
> It's not a regression, I've always seen it to some extent. The issue is that
> the Building Blocks does not use a background-color and the device takes
> some time to get the background image.
> 
> The fix is easy: add a background-color to the action menu BB.

Hey Julien, Sergi does not work for TEF anymore. So, I'm taking this NI in his place. I talked with Arnau and we will add this to the BB.

Comment 8

[Julien Wajsberg [:julienw]]

Thanks José!

(In reply to Jason Smith [:jsmith] from comment #6)
> (In reply to Julien Wajsberg [:julienw] from comment #3)
> > It's not a regression, I've always seen it to some extent. The issue is that
> > the Building Blocks does not use a background-color and the device takes
> > some time to get the background image.
> > 
> > The fix is easy: add a background-color to the action menu BB.
> 
> Then why is there a confirmed regression window in comment 4?

Maybe the background-image changed and is now bigger, revealing this issue more than before?


> Anyways - I don't think this is a blocker - it's a edge case + minor visual
> glitch.

I perfectly agree.

Comment 9

[Julien Wajsberg [:julienw]]

Assigning to José then :)

Comment 10

[José Vittone]

Arnau already propose a patch for this issue, here: https://bugzilla.mozilla.org/show_bug.cgi?id=946520
Performance check is needed. But, apart from that, I would check the z-index on this case ;)

Comment 11

[Julien Wajsberg [:julienw]]

Let's see if the issue is still here.

Comment 12

[Pi Wei Cheng [:piwei] (inactive)]

I cannot reproduce this issue on Flame. The design seems to have changed. At step 3 it says to go to Video app - everything from this point onward is then handled within Video, even though it involves utilizing Messages app. At step 14 if I go back to SMS app I see a draft message, but if I go back to Video app I see the expected behavior which is the replace video menu.

I think this bug is obsolete, or there's some information missing.

Tested on:
Device: Flame 3.0 Master (with unrestricted Memory to avoid running into bug 1151748, KK, full flash)
BuildID: 20150428010206
Gaia: 0636405f0844bf32451a375b2d61a2b16fe33348
Gecko: caf25344f73e
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 40.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0

Comment 13

[Julien Wajsberg [:julienw]]

Thanks; I think the root issue was that we used an image background for this menu without using a fallback color background; under some situations the image background kept in memory was released (likely because we needed memory for something else) and this bug was the result of reloading this image background.

I don't think we use an image background now, but if we wanted to try to reproduce today, I'd first display this menu in the SMS app, then try to replace the video or image, and press "cancel" (with is essentially the same as having an error as described in comment 0) so that we come back to the menu in the SMS app.