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

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.

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.

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

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.

0517 WIP https://github.com/alivedise/gaia/commit/acb30a2a64b30407c27c661e3bc22473e493c435 * Fix lots of bugs. * todo: app window life cycle control * todo: etc...

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

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

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?

All after all, a new design to window management draft is here: https://docs.google.com/presentation/d/1Zq1gkHBoS8tsO6TggorM3Fd-5cZ9QfNHWlBWF3egKbA/edit?usp=sharing

fixed by bug 907013 landed.