This document provides an overview of window management in Firefox OS, including the life cycle, layout, orientation, visibility, child windows, history, and animations. It discusses key concepts like how apps are launched and terminated, how their size is affected by factors like keyboards and fullscreen mode, and how the visibility and orientation of apps are controlled. Special apps like the homescreen, FTU, and lockscreen are also covered.

1. FxOS Window
Management 101
alive

2. Agenda
● Intro
● Life cycle mgmt.
● Layout mgmt.
● Orientation mgmt.
● Visibility mgmt.
● Animation mgmt.
● App-specific UI
● System-wide UI
● Child window mgmt.
● History mgmt.
● Special apps
● Resources

3. FirefoxOS
● Re-implementation of a browser

4. Window Manager
● A window manager is system software that
controls the placement and appearance of
windows within a windowing system in a
graphical user interface.[1]
--wikipedia

5. Window Mgmt in FxOS
● Browser API Wrapper
● Interaction between apps
● App life cycle management
● Transition control
● Orientation/Layout/Visibility management

6. Life Cycle
Management
Window Management

7. Life cycle mgmt. (I)
When an app is launched?
● mozApps API (tap icons on homescreen)
● system message
○ bluetooth-*, telephony-*, sms, notification,
alarm, activity, headset-button
○ System message would tell system app to launch app at background
but app itself may launch itself to foreground.

8. Flow

9. Life cycle mgmt. (II)
How an app is
rendered?
● launch path
● proper mozbrowser
iframe attributes
● container / overlay
/ app specific UI

10. Life cycle mgmt. (III)
When an app is killed?
● Crash inside an app.
● OOM killer kills it.
● Closed in Task Manager.
● window.close

11. Life cycle mgmt. (IV)
When the iframe of the killed app is removed
from DOM tree?
● For active app: after performing closing
animation.
● For inactive app: removed immediately after
being killed.

12. Life cycle mgmt. (V)
When a killed app is relaunched?
● Homescreen: on home button
● Experimental: revive the zombie
app with the same url if it is
opened from task manager or
swiped in from edge gesture.
○ No gecko support yet

13. Life cycle mgmt. (VI)
What happens to a termination?
● For activity, perform opening the activity
caller.
● For popup, perform opening the window.
open caller.
● For app, nothing to do.

14. Layout
Management
Window Management

15. ● System app never resizes until orientation
changes.
● App resized on
○ System app resizes.
○ Keyboard opening/closing animation ends.
○ Statusbar changes.
○ window.resizedBy / window.resizeTo
○ Software home button toggles.
Layout mgmt. (I)

16. Layout mgmt. (II)
App’s size is affected by
● Fullscreen state (manifest.fullscreen)
○ ParentWindow
● Keyboard state
● AttentionScreen state
● Software home button state
● Chrome navigation state

17. App resizing
Fullscreen appNormal app App with keyboard App with Chrome

18. App resizing (cont.)
Normal app when
attention bar is active
App under landscapePopup with keyboard

19. Window Management
Visibility
Management

20. Visibility mgmt. (I)
● System apps goes to background only when
screen is off.
● Page visibility is inheritted while parent
iframe is inactive.
● Page visibility is an important reference to
○ Audio competing
○ Process Proirity
○ Rendering

21. Visibility mgmt. (II)
App goes to foreground
while:
● Opening animation
starts.
● Swipe in animation ends.
● Lockscreen is unlocked.
App goes to background
while:
● Closing animation ends.
● 3 secs after callscreens
comes. (bug attention-
window)
● Screen is off.

22. Visibility mgmt. (III)
Exceptions
● Active app with audio of normal channel
playing
● Inline web activity caller
● window.open(‘’, ‘’, ‘dialog’) opener

23. Orientation
Management
Window Management

24. App Orientation Management

25. Orientation mgmt. (I)
Controlling from app side:
1. manifest.orientation
2. screen.mozLockOrientation / Unlock

26. Orientation mgmt. (II)
What’s affecting the orientation?
1. LockScreen is locked.
2. AttentionScreen is opened.
3. Active activity requests its own orientation.
4. Active popup requests its own orientation.
5. Active app requests its own orientation.

27. Orientation mgmt. (III)
orientationchange event occurs upon:
● App opening animation ends.
● App closing animation begins.
○ Because of homescreen app’s transparency.
orientationchange means resize and reflow!

28. Orientation mgmt. (IV)
Default orientation
● System app would try to acquire default
orientation on bootup.
○ For tablet it’s landscape-primary
○ For mobile it’s portrait-primary
● App could request default orientation in
manifest or orientation API.

29. Orientation mgmt. (V)
If the app doesn’t acquire its orientation
● If orientation-lock setting is not enabled,
unlock the orientation. (means rotatable)
● If orientation-lock setting is enabled, locked
to the default orientation.

30. Window-Specific
UI/UX
Window Management

31. App specific UI/UX
● Modal dialog
● Context Menu
● Shrinking for NFC
● Browser Chrome
● Audio channel service (1.5+)

32. alert/confirm/prompt

33. Context Menu

34. ● No, Not
● For web pages needs back/forward/refresh
functions still.
● Or apps declaring { chrome: { navigation:
true } } in manifest.
● Affects the height of the content.
Browser Chrome

35. Browser Chrome

36. Shrinking

37. Window Management
System-Wide
UI/UX

38. System wide UI
1. Dialog which not belong to a single app but
needs to fit app layout when some events
trigger it.
○ Volume warning dialog
○ SIM PIN unlock dialog
○ Cell Broadcast dialog
2. UI affecting window behavior
○ Software home button

39. Software home button
● Hardware home button alternative
● Automatically enabled on no-hardware-
button device, e.g., Nexus 4.
○ media-query: -moz-physical-home-button
● Affects the size of non-fullscreen app.

40. Home Gesture
● Another hardware home button alternative.
○ While being enabled, swiped from bottom
could perform app closing.
● Automatically enabled on tablet.

41. (CE)Volume warning dialog
Show up while all of the following conditions
are satiesfied.
1. Earphone is plugged.
2. Exceeds volume threshold. ( > 85dB)
3. Content channel audio is playing.
4. First warning or after 20 consecutive hours
while dismissed.

42. SIM PIN unlock dialog
Show up while
● The opening app has telephony permission
in manifest
○ Blacklist: settings and FTU
● Airplane mode is turned off.

43. Window Management
Child Windows
Management

44. An app/page has is opened directly or indirectly
by other app/page.
● Attention window
● Popup window
● Activity window
● Trusted UI / Trusted window
Child window

45. Child window mgmt.
● When a child window terminates normally,
re-open its parent window.
● Some sort of child window may also have
another child window.
● Process priority management between
parent and child is an issue.

46. Activity dispositions
Inline Activity
● Creates a new
reference page to
provide the data to
the activity.
Window Activity
● Reuse the existing
app window to
consume the
activity data.

47. Attention Window
● Used to get your attention
○ Call screen - dialer
○ Alarm screen - clock
● Permission is necessary
● Only portrait primary orientation
● Non modal for now.

48. ● Persona and mozPay API are using.
● Specific sizing: ~80%
● Partial visible homescreen during trustedUI
is running.
Trusted UI

49. Trusted UI - Persona

50. Window Management
History
Management

51. Task Manager
● Reflection of the app history.
● Be able to kill an app actively.
● Optional: Keep zombie app to pretend it is
still alive.
● Future: In app stack reflection.

52. Edge gesture
Edge Gesture - App to app history view

53. Edge Gesture - In app history view

54. Edge gesture
● How to decide next app?
a. Child window of the active app
b. Launch time is just newer
■ Find the head window of the next app stack
● How to decide previous app?
a. Parent window of the active app
b. Launch time is just elder
■ Find the rear window of the previous app stack

55. Task Manager

56. Screenshoting mgmt.
App screenshoting is taken at
● App closing animation ends.
● Getting into task manager.
Screenshoting is expensive!

57. App Animations
Window Management

58. State Machine of App Transitions

59. App Switching Flow

60. 1. Before an app is opening, we need to ensure
it’s recovered from background state.
○ Tricks: take 1x1 screenshot to enforce redraw.
2. After the app is ready to be opened, perform
the opening animation of the next app and
the closing animation of the current app at
the same time.
App transitions (I)

61. App transitions (II)
● Do screen orientations lock/unlock at
opened and at closing.
● Do resizing at opening only if the app is
resized once. Otherwise, skip resizing step.
● Do change page visibility under
screenshoting protection.

62. Special Apps
Window Management

63. Homescreen
● Swappable.
○ Launched via homescreen manifestURL setting.
○ Relaunched while the setting is changed in settings
app or while home button is ensured.
● Higher process priority than other
background app to avoid quick killing.

64. FTU (First Time Usage)
● Launched via FTU ManifestURL setting.
● Only be launched automatically on fresh
flashing.
○ make NOFTU=1 to avoid it.
● Way of app switching is disabled while FTU
is running.

65. Other special apps
● Keyboard
○ Affect the size of active app window.
● Cost control
○ Widget-like iframe inside utility tray.
● Secure camera
○ Layout upon lockscreen.
● Lockscreen
○ Swappable app in the future.

66. Resources
● Architecture slide
○ http://bit.ly/window-mgmt-slide
● JSDOC
○ http://alivedise.github.io/gaia-system-
jsdoc/AppWindow.html
● Meta bug
○ http://bugzil.la/window-management