845251 - [system] Make window manager testable

Status: RESOLVED FIXED

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

Description

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

Window Manager is implemented as module pattern. Now it is having countless private functions, and results in non-testable.

IMO, if a private function has some kind of complexity, it should be migrated to another object/class to be a public function.

This would be a non-trival change and would result in diverge between master and v1-train.

First of all, I think we should break the Window Manager to be different parts.

Agenda:

1. Let mozBrowser iframe create/update go to browserFrame class.
2. Let appWindow create/update mozbrowser iframe creation/update by itself.
3. Abstract the inline activity logic to a new object/class
   or let appWindow deal its own inline activity stack.
4. Move the FTU launch hack out of WM. (bug 814840)
5. Move the payment hack out of WM.
6. Move wrapper(mozbrowseropenwindow by homescreen app) related logic out of WM.
7. TBD...

Comment 1

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

I made a current gaia system architecture diagram:
https://docs.google.com/drawings/d/18DnhTgQBK3M0KBeLGJkWW1hfiYBB6GgTmfdbUnT2SLs/edit

From this I realized that we should wrap any API to its own module for more comfortable unit tests. Then
1. Test the API
2. Test the custom events wrapped from the API
could be diverged.

Comment 2

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

phase.1 WIP 
https://github.com/alivedise/gaia/commits/testable-window-manager

DONE:
now we have a new AppWindow and HomescreenWindow inherited from AppWindow.
1. var u = new AppWindow('app://uitest.gaiamobile.org/index.html', 'app://uitest.gaiamobile.org/manifest.webapp');
2. var h = new HomescreenWindow();
3. h.close();a.open(); //HomescreenWindow has its own transition function.
4. a.swapOut();  //App to app transition

TODO:
Phase 2: Implement AppWindow.swatIn();
Phase 3: Implement Wrapper, inheriting from AppWindow.
Phase 4: Decouple browserFrame and AppWindow.
Phase 5: Implement ActivityWindow, inheriting from AppWindow
Phase 6: Check other app specific mozbrowser API works.
Phase 7: Unit test for each module.

Comment 3

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

Today's WIP
https://github.com/alivedise/gaia/commit/0fe87a9eb466913a4920ae24c16e5d15c0184acd

DONE:
1) Wrapper
2) AppWindow.swapIn(), AppWindow.swapOut();

TODO:
1) WrapperManager(need more flexible name...)
2) browserAPI event connection
3) ActivityWindow
4) Unit tests
5)* Orientation Manager for virtual app-specific lockOrientation, see 840147
6) Coordinate cardview

Comment 4

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

For orientation:
orientation is a global state, however sometimes we need to retain the orientation of an app, in transitioning or in cardview. My thought is add a AppWindow method named for '_lockOrientation'. It's managed by WindowManager, after each orientationchange event, 'virtually' lock the app iframe's orientation by rotating it.

For cardview:
The problem is screenshoting.
Currently it always fetching the mozbrowser iframe screenshot without the UI covered on it and belong to the app. My thought is AppWindow may have a member function and provide the screenshot in 2 cases:
1) No UI is covering on iframe: iframe.getScreenshot result.
2) UI is covering on iframe: AppWindow transform.

Comment 5

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

0517 WIP
https://github.com/alivedise/gaia/commit/acb30a2a64b30407c27c661e3bc22473e493c435

* Fix lots of bugs.
* todo: app window life cycle control
* todo: etc...

Comment 6

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

I am attracted by somewhat more important bugs these day so no update.

Comment 7

[Deepa Subramanian]

Can you please provide steps to verify this fix - as we can perform blackbox testing from the UI?

Comment 8

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

Are you replying the wrong bug?

(In reply to Deepa Subramanian from comment #7)
> Can you please provide steps to verify this fix - as we can perform blackbox
> testing from the UI?

Comment 9

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

All after all, a new design to window management draft is here:

https://docs.google.com/presentation/d/1Zq1gkHBoS8tsO6TggorM3Fd-5cZ9QfNHWlBWF3egKbA/edit?usp=sharing

Comment 10

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

fixed by bug 907013 landed.