856492 - [Wrapper] double tapping home button will show the wrapper around the homescreen (regression)

Status: RESOLVED DUPLICATE of bug 868286

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

Description

[Tony Chung [:tchung]]

Attachment: screenshot

+++ This bug was initially created as a clone of Bug #823986 +++

This bug has regressed.  i'm seeing this on 20130331 nightly builds, leo device.

Repro is the same as below:

Found device
Gecko  http://hg.mozilla.org/releases/mozilla-b2g18/rev/f9f11b8cbf8a
Gaia   5a1ead9c8f831167fd86464d21eea310c7082112
BuildID 20130331070203
Version 18.0

---------------
old repro:

You can get the browser wrapper to wrap around the homescreen and any core apps.  This is caused after trying to double tap home button when a e.me app (or browser bookmark) is open

Screenshot.

Repro:
1) install nightly unagi build, 20121220092540
2) add a browser bookmark or e.me app to the homescreen
3) launch that bookmark or e.me app
4) double tap the system Home button.
5) Verify app exits, and the homescreen is within the wrapper

Expected;
- double tapping should kill the wrapper as well

Actusl;
- wrapper stays.  you can proceed with using the phone within the wrapper.

Comment 1

[Lukas Blakk [:lsblakk] use ?needinfo]

Blocking and let's get a regression range.

Comment 2

[Angela Hubenya]

I will work on finding the regression window for this issue.

Comment 3

[Angela Hubenya]

Here are the regression window results: 

b2g18 build 20130314114915 – Pass 
b2g18 build 20130315070220 - Fail

Comment 4

[(inactive after 6/18) Alive Kuo [:alive]]

Why this one is leo+? This only exists in gaia master.

Comment 5

[Alex Keybl [:akeybl]]

(In reply to Alive Kuo [:alive] from comment #4)
> Why this one is leo+? This only exists in gaia master.

Comment 3 suggests otherwise. What makes you think this is only on master?

Comment 6

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Alex Keybl [:akeybl] from comment #5)
> (In reply to Alive Kuo [:alive] from comment #4)
> > Why this one is leo+? This only exists in gaia master.
> 
> Comment 3 suggests otherwise. What makes you think this is only on master?

Because I cannot repro this on v1-train.

Comment 7

[Angela Hubenya]

I was able to repro this on today's v1 train, and master. 

Environmental  Variables:
Unagi Build ID: 20130410070209
Kernel Date: Dec 5
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/423f7851bdb5
Gaia: c614b3f3c956dc1e1adf93cf4cf41511ce75de80 


Environmental  Variables:
Unagi Build ID: 20130410065939
Kernel Date: Dec 5
Gecko: http://hg.mozilla.org/mozilla-central/rev/ee5ca214e87c
Gaia: f6587418cc5fd8dfe885539ae1a798473890c7f5

Comment 8

[(inactive after 6/18) Alive Kuo [:alive]]

Ignore my comment because my v1-train seems outdated.
I ran into this today and is investigating, stealing.

The root cause is by patch of bug 849441, which tries to solve the wrapper footer is delaying to disappear. I am looking for a way to resolve that and this.

Comment 9

[(inactive after 6/18) Alive Kuo [:alive]]

It's another mess-up in WM. All open/close transition is asynchronous and move the code to elsewhere may cause race condition.
IMO the silver bullet would be `Move the wrapper UI into individual appWindow` instead of keeping it as global UI in `#windows`.

Comment 10

[(inactive after 6/18) Alive Kuo [:alive]]

Decoupling wrapper from window manager - WIP v0.5
https://github.com/alivedise/gaia/commit/4ea2d21c7fbb417ffcb5ecd29dffc84091474d6d

TODO:
* Decoupling strange browserFrame generation flow from window manager
* Unit test if possible

Comment 11

[(inactive after 6/18) Alive Kuo [:alive]]

Decoupling wrapper - WIP v2.0
https://github.com/alivedise/gaia/commit/cf813687da5fddaed52d3b1153f1913c3e84e618

Still working on keep wrapper-manager as clean as possible.
Hence the expected flow of wrapper activation is:
1. mozbrowserwindowopen handler (wrapper manager) gets an event from homescreen.
2. After parsing the detail, format a configuration object to AppWindow
3. AppWindow by config calls new BrowserFrame() or BrowserFrame.browserize(existingIframe)
4. (still thinking) AppWindow tells WindowManager we've created/updated a new App Window which type is |wrapper|.
5. WindowManager renews runningApp list.

Comment 12

[(inactive after 6/18) Alive Kuo [:alive]]

Bug 868286 gives a quick fix to this problem, but I will continue my work in another bug.