Mid level introduction to the Javascript based window management system of FxOS

1. Architecture, Development, Patterns

2. Window Manager
A core module in an operating system, which is
responsible to display and maintain the window
based UI.

3. Window Mgmt. at FxOS
● A clustor of modules mainly serves to create
web apps.
● A re-implementation of a browser.
● Ability to handle WebAPI request between
apps.

5. Things inside..

6. Window Manager (v1.3-)
Modal
Dialog
Truste
UI
AuthDi
alog
transition control
create
mozbrowser
iframe maintain app life
cycle
gen screenshots
redirect
mozbrowser
events
orientation
control
layout control
error handling
visibility control
web activities
management
web app
management
manage
homescreen
manage ftu

7. It’s sad to have a such giant module to
control everything :(

8. The secret to build a large app ?

9. The secret to build a large app ?
Never build a large app

10. Solutions
Instances +
Manager +
Scalable Patterns

11. INSTANCES
Minimal operable unit

12. AppWindow
● The basic unit which wraps the mozbrowser
iframe.
● (Mostly) Standalone library to create a
webapp instance.
● Each appWindow instance maintains its own
states and display proper UI according to
these states.

14. Extra chrome UI
Real web content

15. AppWindow States
● Visibility: |document.hidden|
● Orientation: screen.orientation
● Layout: window.innerHeight/innerWidth
● Transition
● Loading
● Title, icon, ….

16. App Visibility
● Active app is basically foreground, but we
are having some more complex rules; for
instance, a chaining activities are all
foreground.
● Page visibility is particially impacting the
process priority.
● The timing of visibilitychange was bind to
transition states.

17. App Orientation
● Passive orientation requested in manifest
● Active orientation requested by
screen.lockOrientation()
o System app does not being involed too
much in this progress but is expected to.
o What if lock orientation during
transitioning?
● Query by screen.mozOrientation

18. App has no knowledge about (x, y),
but (w, h) is affecting app by window.innerHeight,
window.innerWidth, and reflow/resize if that changed.
Layout = (x, y,
w, h)

19. Use small piece of codes
doing limited tasks
AppWindow: Submodule
To avoid a giant AppWindow class..

20. AppWindow Submodules
AppWindow
Each submodule is responsible to handle a specific request
from the appWindow. Their only dependency is the
appWindow who launches/instantiates them.
M
M
M
M
M
MHW
M
M
M
M
M M
At
W
M
M
M
M
M
M
submodule

21. Current
Submodules
AppWindow
ModalDialog
AuthenticationDialog
TransitionController
Chrome
ContextMenu
childWindowFactory
window.alert
window.open
HTTP Auth
chrome property
<contextmenu>
Transition State Machine
<iframe mozBrowser>

22. Developing Submodules
var MyModule = function(app) {
this.app = app;
this.app.element.addEventListener(‘_opened’, this);
};
MyModule.prototype = {
handleEvent: function() {
// ...
}
};
AppWindow.SUB_MODULES = {
‘myModule’: window.MyModule
};
var a = new AppWindow();
typeof(a.myModule) // === MyModule

23. Transition Finite State Machine
● A submodule to process transition related
events to maintain the state and perform the
transition.
● States: opened/opening/closed/closing
● Transition state should be standalone from
other states.

24. openedclosed
opening
closing
AppWindow
AppWindow does not care the state maintainence, but
only ask the finite state machine to process events

25. openedclosed
opening
closing
AppWindow
Whenever state is changed, transition FSM will
publish events for the app.

26. Interactions between AppWindows..
We are living in a world of multiple apps. An
appWindow should not do anything it wants to
do.
Request before permitted!

27. MANAGERS
Managing multiple standalone instances

28. If all the subordinates are standalone
The job of a manager is easy!

29. Manager
● Lifecycle Management
● Hierarchy Management

30. LifeCycle Management
● Maintain a list of alive windows
● Manage the interaction between window
instances
● Events happens inside an appWindow is
delegated to the appWindow itself.
● Interactions involved multiple appWindows
needs the manager to decide what to do.

31. Life cycle - launch
● AppWindowManager has an appWindow
factory to deal with launch request from the
gecko(system message) or the user.
● Each AppWindow instances has a child
window factory to deal with launch request
from the app.

32. AppWindowManager
#AppWindow
Gecko
webapps-launch open-app
Factory
Factory
mozbrowseropenwindow
launchactivity
#AppWindow
Factor
y
#AppWindow
Factor
y
#AppWindow
Factor
y
#AppWindow
Factor
y #PopupWindow
Factor
y
#ActivityWindow
Factor
y
#AttentionWindow
appopenwindow

33. Life cycle - kill
● active kill
o window.close()
o ParentWindow is killed
o The user kills it from task manager.
● When an appWindow is killed inactively by
gecko due to OOM or crash, it will enter
suspend state.

34. appWindow
SuspendingWindowManager
suspended
appWindow
suspended
appWindow
suspended
mozbrowsererror
mozbrowsererror
mozbrowsererror

35. appWindow
timestamp: 1
SuspendingWindowManager
appWindow
timestamp: 0
appWindow
timestamp: 2
resumedlaunch

36. appWindow
timestamp: 1
SuspendingWindowManager
appWindow
timestamp: 0
appWindow
timestamp: 9
appWindow
timestamp: 10
suspended
kill the oldest

37. *WindowManager
*Window *Window (active)
Modules affecting
transition
*Window
Transition
FSM
*Window
request to open
close the active instance
Basically only the same
type window will be taken
into account.

38. WindowManager
*Window *Window
Modules affecting
transition
*DialogManager
Transition
FSM
*Window
admit the request or ignore by
*Window.open();

39. MultiTasking - Nested Windows
Dialer App Gallery AppHomescreen App Contact App
Contact Activity
Gallery Activity
Camera Activity
Camera App

40. MultiTasking - Nested Windows
AppWindow
AppWindowAppWindow
AppWindow
ActivityWindow
Activity
Window
ActivityWindow
AppWindow
FrontWindow is rendered inside BottomWindow’s container.

41. AppWindow#1
Activity
Window#A
Nested Window
Activity
Window#B
● AppWindow#1 manages ActivityWindow#A
● ActivityWindow#A manages ActivityWindow#B
● Only parentWindow/childWindow refers each
other; the grandparentWindow(AppWindow#1)
does not need to know the state of the
grandchildWindow(ActivityWindow#B)
● However, kill a parentWindow will kill the
childWindow which causes a chaining kill.

42. We are having a principal pattern now.
AppWindowManagerAppWindow AppWindow
Application Core
AppWindow AppWindow
AppWindow
One Manager + Instances Pattern fits usual webapp
management requirements.

43. Hierarchy
In an operation system, there would be some
system level user interface which are not usual
applications but has certain interaction with
applications.
Lockscreen, Attention, SystemDialog,
Rocketbar...

44. We are having a principal pattern now.
Scale this design.

45. One App =>
Multiple App =>
Multiple Tasking =>
Multiple Hierachy

46. AppWindowManagerAppWindow AppWindow
Application Core
LockscreenWindow
Manager
Lockscreen
Window
Ability to extend the manager

47. AppWindowManagerAppWindow AppWindow
Application Core
LockscreenWindow
Manager
Lockscreen
Window
Keep the interactions between new
windows
AttentionWindow
Manager
Attention
Window
Attention
Window

48. Manager of Managers
Hierarchy management

49. Hierarchy Management
● Visibility Management
● Orientation Management
● Layout Management

50. Lowlevel Windows
Highlevel Windows
Manager
1. Request
2. Detect
3.Perform/
Ignore
Operations across windows is controlled by specfic manager.

51. Hierarchy events
● resize
● orientation
● visibility
● home

52. Hierarchy Management
● Visibility Management
● Orientation Management
● Layout Management

53. LayoutManager
*Window
KeyboardManager SoftwareHomeButton
*WindowManager
*Window *Window *Window
*WindowManager*WindowManager
dispatch resize command to
highest priority manager
Modules affecting
layout
execute resize to active window
resize

54. VisibilityManager
*Window
*Window *Window
*WindowManager*WindowManager*WindowManager
dispatch background command to
lower priority manager
Modules affecting
visibility
execute setVisible to active window
*DialogManager
*Window

55. VisibilityManager
*Window *Window
Modules affecting
visibility
*DialogManager
Transition
FSM
request to foreground
*Window
Check no higher priority module is active

56. VisibilityManager
*Window *Window
Modules affecting
visibility
*DialogManager
Transition
FSM
*Window
admit the request or ignore
by *Window.setVisible(true)

57. OrientationManager
*Window *Window
Modules affecting
orientation
*DialogManager
Transition
FSM
*Window
request lock orientation
Check no higher priority module is active

58. OrientationManager
*Window *Window
Modules affecting
orientation
*DialogManager
Transition
FSM
*Window
admit the request or ignore
This is not real now.
screen.requestLockOri
entation() is open to
web content.
System app should
have the ability to
manage orientation
request from
mozbrowser iframe.

59. Look at the Transition FSM closely
● statechange will trigger the inner handler
o Enter closed state: send to background
o Enter opened state: request to foreground

60. Develop a window manager
● What windows to manage/create?
● Reuse/Inherit AppWindow
● Make HierachyManagement Modules know
your existence

61. Best Practice: Rocketbar
● Search app is different from a normal
appWindow.
● Implement SearchWindow
● Implement
SearchWindowManager(rocketbar.js)
● Modify HierachyManagement Modules

62. PATTERNS USED

63. Patterns
● Manager Pattern
● *Observer Pattern
● Finite State Machine Pattern

64. Manager(Mediator) Pattern
● A manager is usually a singleton.
● What to manage? Interactions between
instances.
● A manager is expected to maintain a list
multiple instances coming from the same
class.

65. InstanceA
Manager
InstanceB
InstanceC
Instances should issue a request which needs cross instance knowledge to manager.
request an operation across instances

66. InstanceA
Manager
InstanceB
InstanceC
InstanceA has no knowledge about instanceB.
check states

67. InstanceA
Manager
InstanceB
InstanceC
permit the request after checking
other instances

68. Patterns
● Manager Pattern
● *Observer Pattern
● Finite State Machine

69. Event Publisher/Broadcaster Inner Subscriber
Inner Subscriber
Inner Subscriber
Outer Subscriber
Outer Subscriber
Outer Subscriber
Inside a module
The world

70. Event Publisher/Broadcaster Inner Subscriber
Inner Subscriber
Inner Subscriber
Outer Subscriber
Outer Subscriber
Outer Subscriber
Inside a module
The world

71. Patterns
● Manager Pattern
● *Observer Pattern
● Finite State Machine + Proxy

72. Finite State MachineEvents
FSM.processEvent(‘a’);
FSM.processEvent(‘a’);
FSM.processEvent(‘b’);
FSM.processEvent(‘c’);
statechange