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

RESOLVED DUPLICATE of bug 868286

Status

Firefox OS
Gaia::System
RESOLVED DUPLICATE of bug 868286
5 years ago
5 years ago

People

(Reporter: tchung, Assigned: alive)

Tracking

({regression})

unspecified
ARM
Gonk (Firefox OS)
regression
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:leo+)

Details

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
Created attachment 731734 [details]
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.
(Reporter)

Updated

5 years ago
Summary: [Wrapper] double tapping home button will show the wrapper around the homescreen → [Wrapper] double tapping home button will show the wrapper around the homescreen (regression)
Component: Gaia::Homescreen → Gaia::System
Blocking and let's get a regression range.
Assignee: nobody → 21
blocking-b2g: leo? → leo+
Keywords: regressionwindow-wanted

Comment 2

5 years ago
I will work on finding the regression window for this issue.
QA Contact: ahubenya

Comment 3

5 years ago
Here are the regression window results: 

b2g18 build 20130314114915 – Pass 
b2g18 build 20130315070220 - Fail
Keywords: regressionwindow-wanted
Why this one is leo+? This only exists in gaia master.
blocking-b2g: leo+ → leo?

Comment 5

5 years ago
(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?
blocking-b2g: leo? → leo+
(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

5 years ago
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.
Assignee: 21 → 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`.
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.
Blocks: 845251
Bug 868286 gives a quick fix to this problem, but I will continue my work in another bug.
Blocks: 868324
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 868324
Duplicate of bug: 868286
Blocks: 870708
No longer blocks: 870708
You need to log in before you can comment on or make changes to this bug.