1091543 - activeApp.getTopMostWindow() does not work when activityWindow launched by search app

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::UI Tests, defect)

Description

[Zac C (:zac)]

STR:
1. Disable internet connection on the phone
2. Start a search using the rocketbar
3. In search results, tap "No internet connection" 
[Settings activityWindow opens]
4. probe window.AppWindowManager._activeApp.getTopMostWindow().name using WebIDE

The window returned will be the Homescreen.

It should be the Settings app which is open in an activityWindow instance and is the window that is user facing.


Build under test:
Gaia-Rev        30e37915865af8eb8164a50e7512e68f40967961
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/7e3c85754d32
Build-ID        20141029040208
Version         36.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141029.085747
FW-Date         Wed Oct 29 08:58:02 EDT 2014
Bootloader      L1TC00011880

Comment 1

[Zac C (:zac)]

Alive, can you verify the correct behaviour?
Or is there an alternative way to get the absolute top window (aside from document.elementFromPoint!)?

Comment 2

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

Before bug 1079748 is implemented, we could workaround in GaiaApps:
if (window.rocketbar.active) {
  return window.rocketbar.searchWindow.getTopMostWindow();
} else {
  return window.appWindowManager.getActiveApp().getTopMostWindow();
}

Ya, the reason is we are growing with different new window managers and their hierarchy(z-ordering) is different. AppWindowManager is not the right place to ask when we are living in a world that there are multiple window managers.
Bug 1079748 will provide a general solution to access top most UI(including windows and dialogs) from anywhere.

Comment 3

[Zac C (:zac)]

Thanks Alive!

We'll update our atom as per your suggestions.

Comment 4

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

BTW this case sounds like side effect of bug 1007600.

Arthur, maybe we should launch window disposition of settings for 404 error page.
https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/net_error.js#L148

Otherwise we will have many connection page inside each browser window when we have no network.

Let's do this in another bug if you agree.

Comment 5

[Zac C (:zac)]

Attachment: github pr

Comment 6

[Arthur Chen [:arthurcc][inactive after 6/30]]

The connection page should be closed when pressing the home button. Not sure why there would be multiple connection pages existing.

And using inline activity makes sense in the use case where users want to configure the connectivity settings in the context without affecting the existing instance of settings app.

Comment 7

[Florin Strugariu [:Bebe]]

merged in https://github.com/mozilla-b2g/gaia/commit/5b297938fcf3d7932722983b08ce8e961d75a151

Comment 8

[Florin Strugariu [:Bebe]]

Do we need this on v2.1

Comment 9

[Zac C (:zac)]

I don't think we need to put this on v2.1.