1011611 - [B2G][Flame]Double-tapping on Share with email option for website and selecting Cancel causes device to become non-responsive while using Cellular & Data

Status: RESOLVED FIXED

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

Description

[Montoya Clemmons (MClemmons)]

User taps Browser App and navigates to a website (i.e. google.com) using Cellular & Data. User taps share with email option with a double-tapping motion to cause the next screen to appear. However, when user makes the Cancel selection, the screen returns to the homescreen with no apps, just the wallpaper and a faded black display. User's only option is to restart the device. 

Prerequisites:
1. Enable Cellular & Data in Settings

Repro Steps:
1) Updated Flame to BuildID: 20140515000202 
2) Tap Browser App
3) Navigate to any website (i.e. google.com)
4) Double-tap the share with icon in lower right 
5) Tap Cancel and observe the screen

Actual:
Screen returns to the homescreen with no apps, just the wallpaper and a faded black display. User's only option is to restart the device. 

Expected:
Screen returns to the website page previously selected 

Notes:
Repro frequency: 7/10 – 70%
See attached: video clip = https://www.youtube.com/watch?v=fitx8nCGrR8

Environmental Variables: 
Device: Flame 1.4 MOZ 
BuildID: 20140515000202 
Gaia: 2e97bee6bb79d3577dba1bf2a1bbfcba64ee99ab 
Gecko: 0cb91945f404 
Version: 30.0
Base: v10F-3

Comment 1

[Montoya Clemmons (MClemmons)]

This issue does reproduce on Buri 1.4 following the STR from Comment 0. The screen returns to the homescreen with no apps, just the wallpaper and a faded black display. User's only option is to restart the device. 

Environmental Variables: 
Device: Buri 1.4 MOZ 
BuildID: 20140515000202 
Gaia: 2e97bee6bb79d3577dba1bf2a1bbfcba64ee99ab 
Gecko: 0cb91945f404 
Version: 30.0
Firmware Version: v1.2-device.cfg

Comment 2

[Montoya Clemmons (MClemmons)]

This issue does not reproduce on v10F-3 without 1.4 following the STR from Comment 0. After 25 repro attempts, device screen never became non-responsive.

Comment 3

[Montoya Clemmons (MClemmons)]

This issue does not reproduce on Buri 1.3 following the STR from Comment 0. After 25 repro attempts, device screen never became non-responsive.

Environmental Variables: 
Device: Buri 1.3 MOZ 
BuildID: 20140515024003 
Gaia: 96e3fa769a436a2182e6d54088fb41386eb2b5b5 
Gecko: 2e902c53be8d 
Version: 28.0
Firmware Version: v1.2-device.cfg

Comment 4

[Duane Dixon [:ddixon]]

Regression Window: issue DOES occur in earliest 1.4 Flame build we have access to.

Environmental Variables:
Device: Flame 1.4 
BuildID: 20140424123005
Gaia: fc95009476fac9ce205a59b237d146ca7f6f42e7
Gecko: 37237034e45c
Version: 30.0a2
Firmware Version: v10F-3

Comment 5

[Jason Smith [:jsmith]]

Try doing the window on Buri then.

Comment 6

[Duane Dixon [:ddixon]]

Buri Regression Window: Issue DOES NOT occur in latest 2.0 Central Buri build.  

Environmental Variables:
Device: Buri 2.0 
BuildID: 20140521050919
Gaia: 7c55cc2baabc2d66d512768e79b9cbc67bb83040
Gecko: b9e1856deef1
Version: 32.0a1
Firmware Version: v1.2-device.cfg

NOTE: Issue DOES NOT occur in earliest 2.0 Central Buri build we have access to.

Comment 7

[Jason Smith [:jsmith]]

Try doing the window on 1.4 Buri then, since comment 1 says it's reproducible there.

Comment 8

[Duane Dixon [:ddixon]]

Unable to provide Buri 1.4 Regression Window.  

Issue DOES occur in ALL 1.4 Buri builds we have access to. 

(Earliest 1.4 Buri variables) 

Environmental Variables:
Device: Buri 1.4 
BuildID: 20140422102131
Gaia: 58578bcb4886c66fb30038c071e460fd57e49102
Gecko: a86cef581475
Version: 30.0a2
Firmware Version: v1.2-device.cfg

Comment 9

[Jason Smith [:jsmith]]

Then let's get the window against builds while 1.4 was trunk.

Comment 10

[Duane Dixon [:ddixon]]

Regression Window for Buri 1.4 trunk: 

Last Working: 

Environmental Variables:
Device: Buri 1.4
BuildID: 20140315121740
Gaia: f09ec7d9d0bb7c40998ddb6b5bf397e578add541
Gecko: fb7fef480e48
Version: 30.0a1
Firmware Version: v1.2-device.cfg

First Broken:
 
Environmental Variables:
Device: Buri 1.4
BuildID: 20140315122440
Gaia: 70978988d048737b1379f5452a679429dadcd35f
Gecko: ba4c5a81d56a
Version: 30.0a1
Firmware Version: v1.2-device.cfg


Last Working Gecko and First Broken Gaia
Issue DOES occur here.
Gaia: 70978988d048737b1379f5452a679429dadcd35f
Gecko: fb7fef480e48

Last Working Gaia and First Broken Gecko
Issue DOES NOT occur here. 
Gaia: f09ec7d9d0bb7c40998ddb6b5bf397e578add541
Gecko: ba4c5a81d56a

Gaia Pushlog: 
https://github.com/mozilla-b2g/gaia/compare/f09ec7d9d0bb7c40998ddb6b5bf397e578add541...70978988d048737b1379f5452a679429dadcd35f

Comment 11

[Preeti Raghunath(:Preeti)]

Tim

Can you please review and reassign? Seems to be a window management issue

Comment 12

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Yeah I was waiting for the regression range...

(In reply to ddixon from comment #10)
> Gaia Pushlog: 
> https://github.com/mozilla-b2g/gaia/compare/
> f09ec7d9d0bb7c40998ddb6b5bf397e578add541...
> 70978988d048737b1379f5452a679429dadcd35f

Sounds like a FxA bug to me since other commits does not touches system.
Bug 897600

Fred, do you have free cycle to deal with this 1.4+? Thanks.

Comment 13

[[e-mail]]

start checking it

Comment 14

[[e-mail]]

Attachment: pull request redirect to github

It can be reproduced in wifi mode as well in v1.4.

It happens because double tap will trigger two mozActivity call. 
Make the activity be called no more than one time every X seconds can fix it.

Comment 15

[[e-mail]]

v2.0 can not reproduce this problem because the activity selection menu for Email & messages popped instead of directly go to Email in v1.4. (in 2.0, Email & messages both support url activity)

Comment 16

[Tim Guan-tin Chien [:timdream] (please needinfo)]

This is strange because the regression range does not indicate anything involving activity handling changes in Gaia system nor any change in Browser app. Nor in Gecko.

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=fb7fef480e48&tochange=ba4c5a81d56a

That said, we should land the patch if this is consider a blocking bug.

Comment 17

[Dale Harvey (:daleharvey)]

The patch looks wrong, 1. why does stuff break when we fire 2 mozactivities, it shouldnt, 2. We should disable the button while the activity is active, and enable when the activity is complete (onerror / onsuccess)

Comment 18

[[e-mail]]

Comment on attachment 8428494 [details] [review]
pull request redirect to github

will provide another patch based on dale's comment

Comment 19

[[e-mail]]

Attachment: PR2

disable share button before the activity is complete

Comment 20

[Dale Harvey (:daleharvey)]

Comment on attachment 8428979 [details] [review]
PR2

This looks good, I was able to reproduce the failure on master by disabling sms sharing and confirmed the fix.

I dont think the test failure is related, I restarted travis to check

Comment 21

[[e-mail]]

thanks for review. 

I think I should also apply this patch for master? It might reproduced in 2.0 tablet since tablet does not have SMS app.

Comment 22

[Dale Harvey (:daleharvey)]

Yup this should definitely go in master

Comment 23

[[e-mail]]

merged to 

v1.4 https://github.com/mozilla-b2g/gaia/commit/cd595be0a8e975559e8938830df5face89bec3e8
master https://github.com/mozilla-b2g/gaia/commit/9d651c75d3f4a1168f74079a1a813ffe715c2fdd

thanks!