+++ 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.

Blocking and let's get a regression range.

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

Here are the regression window results: b2g18 build 20130314114915 – Pass b2g18 build 20130315070220 - Fail

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

(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?

(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.

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

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.

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`.

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

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.

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