[system] Make window manager testable

RESOLVED FIXED

Status

Firefox OS
Gaia::System::Window Mgmt
RESOLVED FIXED
4 years ago
3 years ago

People

(Reporter: alive, Assigned: alive)

Tracking

(Depends on: 6 bugs, Blocks: 2 bugs)

Firefox Tracking Flags

(Not tracked)

Details

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...
Depends on: 814840
Depends on: 856492
Depends on: 854759
Depends on: 868324
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.
Depends on: 868348
Blocks: 870708
No longer blocks: 870708
Depends on: 870708
Depends on: 870717
Whiteboard: [TAIPEI_FND_TRACKING]
Depends on: 871916
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
Depends on: 840147
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...
Depends on: 873961
I am attracted by somewhat more important bugs these day so no update.
Depends on: 877993
Depends on: 877997
Depends on: 871919
Depends on: 880572
Depends on: 877903
Depends on: 884660
Depends on: 880588
Depends on: 885676
Blocks: 887626
No longer depends on: 880588
Blocks: 887650
Blocks: 888889
No longer blocks: 888889

Comment 7

4 years ago
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?
Blocks: 898307
Depends on: 898385
All after all, a new design to window management draft is here:

https://docs.google.com/presentation/d/1Zq1gkHBoS8tsO6TggorM3Fd-5cZ9QfNHWlBWF3egKbA/edit?usp=sharing
Depends on: 902766
Depends on: 905006
Whiteboard: [TAIPEI_FND_TRACKING]
Blocks: 918790
No longer blocks: 918790
Depends on: 935260
No longer depends on: 935260

Updated

4 years ago
Component: Gaia::System → Gaia::System::Window Mgmt
fixed by bug 907013 landed.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.