[Everything.Me][Smart Collections] User will run into a black screen when adding a smart collection to the homescreen

VERIFIED FIXED in 2.2 S5 (6feb)

Status

defect
VERIFIED FIXED
5 years ago
4 years ago

People

(Reporter: dharris, Assigned: alive)

Tracking

({regression})

unspecified
2.2 S5 (6feb)
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(blocking-b2g:2.2+, b2g-v2.1 unaffected, b2g-v2.2 verified, b2g-master verified)

Details

(Whiteboard: [3.0-Daily-Testing][systemsfe], )

Attachments

(2 attachments)

Description:
If the user attempts to add a smart collection to the homescreen they will be opened up into a black screen. If the user then scrolls on this screen, the list of available smart collection appears. If the user only taps on the screen, they will be returned to the homescreen.


Repro Steps:
1) Update a Flame to 20150122010203
2) Go to blank space on Homescreen and long press to access Homescreen Menu
3) Tap "Add Smart Collections"


Actual:
The screen will appear black until the user scrolls the screen


Expected:
The user is shown the list of selectable smart collections

Environmental Variables:
Device: Flame 3.0 (319Mb)(Kitkat)(Full Flash)
Build ID: 20150122010203
Gaia: 917b6c36717fddc6e71ffc1ec249633c8044c93c
Gecko: 34e2d2bd7ec4
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 38.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0

Repro frequency: 10/10 100%
See attached: Logcat, Video - http://youtu.be/0hjoBG-_V20
This issue does NOT occur on Flame 2.2

If the user taps on "add smart collections" they will be shown a list of available smart collection

Device: Flame 2.2 (319MB)(Kitkat)(Full Flash)
BuildID: 20150122002808
Gaia: e4f9b5da3751798f9cc5d95f302c30722cc11fca
Gecko: 4a90da67661e
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 37.0a2 (2.2)
Firmware: V18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Please ignore the video link in comment 0. The correct video link can be found here: http://youtu.be/62aviBPdqaI
[Blocking Requested - why for this release]:
Functional regression of a core feature.

Requesting a window.
blocking-b2g: --- → 3.0?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
QA Contact: jmercado
This issue actually DOES occur on Flame 2.2.  Performing the regression window with this information in mind.

Environmental Variables:
Device: Flame 2.2
BuildID: 20150122140756
Gaia: 2c576dbbe6b5126c427c29609d55de2f6f4d90cf
Gecko: 4047ab9ee909
Version: 37.0a2 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0


It does NOT occur on Flame 2.1.

Device: Flame 2.1
BuildID: 20150122140947
Gaia: 2119de79b6edfbcd4f112b2f797dbd7dba17ea69
Gecko: 804697da948c
Gonk: Could not pull gonk.  Did you shallow Flash?
Version: 34.0 (2.1) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Adjusting nom then accordingly.
blocking-b2g: 3.0? → 2.2?
This issue is caused by bug 1062819.  A prerequisite not mentioned in comment 0 is that SIM lock must be enabled in order for this issue to reproduce.

B2g-inbound Regression Window

Last Working 
Environmental Variables:
Device: Flame 2.2
BuildID: 20141106221308
Gaia: 284253475469b58d549fa48aee67dd1fc814dbc9
Gecko: 90d6489edae2
Version: 36.0a1 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

First Broken 
Environmental Variables:
Device: Flame 2.2
BuildID: 20141106225407
Gaia: 83eaaae5fc609aa414d27a13a0237acb2d647a3a
Gecko: 742640491a42
Version: 36.0a1 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Last Working gaia / First Broken gecko - Issue does NOT occur
Gaia: 284253475469b58d549fa48aee67dd1fc814dbc9
Gecko: 742640491a42

First Broken gaia / Last Working gecko - Issue DOES occur
Gaia: 83eaaae5fc609aa414d27a13a0237acb2d647a3a
Gecko: 90d6489edae2

Gaia Pushlog: https://github.com/mozilla-b2g/gaia/compare/284253475469b58d549fa48aee67dd1fc814dbc9...83eaaae5fc609aa414d27a13a0237acb2d647a3a
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Alive, can you take a look at this please? The work done on bug 1062819 might be the culprit here.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker) → needinfo?(alive)
Interesting, I will take a look.
Component: Gaia::Everything.me → Gaia::System
Flags: needinfo?(alive)
Assignee: nobody → alive
Comment on attachment 8554484 [details] [review]
[PullReq] alivedise:bugzilla/1124816/collection-become-black to mozilla-b2g:master

The root cause is SimLockManager is active while the activity requires focus.
However, instead of fixing that in SimLockManager, I prefer to have a general solution so I changed the ATC#shouldFocus logic to check if our window is top most and deprecate SimLockManager#isActive since it's not needed by anyone.
Attachment #8554484 - Flags: review?(etienne)
Comment on attachment 8554484 [details] [review]
[PullReq] alivedise:bugzilla/1124816/collection-become-black to mozilla-b2g:master

Some bike-shedding on github but then we should be good to go :)
Attachment #8554484 - Flags: review?(etienne)
Whiteboard: [3.0-Daily-Testing] → [3.0-Daily-Testing][systemsfe]
blocking-b2g: 2.2? → 2.2+
Comment on attachment 8554484 [details] [review]
[PullReq] alivedise:bugzilla/1124816/collection-become-black to mozilla-b2g:master

Come up with AppWindow.prototype.HIERARCHY_MANAGER = 'AppWindowManager';
and found that I missed the case SearchWindow's manager is not SearchWindowManager but Rocketbar in original design :/ Good advise!

The pros is the value will be inherited to the same type of subwindows with prototype.

Lemme know what you think.
Attachment #8554484 - Flags: review?(etienne)
Comment on attachment 8554484 [details] [review]
[PullReq] alivedise:bugzilla/1124816/collection-become-black to mozilla-b2g:master

I like it a lot actually :)
Attachment #8554484 - Flags: review?(etienne) → review+
This issue is verified fixed on the latest Central Nightly build.

Actual results: The user does not see a black screen when adding a collection (0/5 reproductions).

Environmental Variables:
Device: Flame 3.0
BuildID: 20150203055641
Gaia: ae5a1580da948c3b9f93528146b007fc4f6a712b
Gecko: ae5d04409cd9
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 38.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0
Status: RESOLVED → VERIFIED
Flags: needinfo?(ktucker)
Flags: needinfo?(ktucker)
Please request Gaia v2.2 approval on this when you get a chance.
Flags: needinfo?(alive)
Target Milestone: --- → 2.2 S5 (6feb)
Comment on attachment 8554484 [details] [review]
[PullReq] alivedise:bugzilla/1124816/collection-become-black to mozilla-b2g:master

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #):
Regression from bug 1062819.
[User impact] if declined:
User cannot use collection
[Testing completed]: Y
[Risk to taking this patch] (and alternatives if risky): Riskless.
In bug 1062819 we refactor the whole sim lock dialog and mistakenly to set it as blocking the focus of the active app window. This patch is fixing all this kind of issue by the hierarchy manager introduced recently.
[String changes made]: NaN
Flags: needinfo?(alive)
Attachment #8554484 - Flags: approval-gaia-v2.2?
Duplicate of this bug: 1109943
Attachment #8554484 - Flags: approval-gaia-v2.2? → approval-gaia-v2.2+
You need to log in before you can comment on or make changes to this bug.