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.
Life cycle mgmt. (II)
How an app is
● launch path
● proper mozbrowser
● container / overlay
/ app specific UI
Life cycle mgmt. (III)
When an app is killed?
● Crash inside an app.
● OOM killer kills it.
● Closed in Task Manager.
Life cycle mgmt. (IV)
When the iframe of the killed app is removed
from DOM tree?
● For active app: after performing closing
● For inactive app: removed immediately after
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
Life cycle mgmt. (VI)
What happens to a termination?
● For activity, perform opening the activity
● For popup, perform opening the window.
● For app, nothing to do.
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
Visibility mgmt. (II)
App goes to foreground
● Opening animation
● Swipe in animation ends.
● Lockscreen is unlocked.
App goes to background
● Closing animation ends.
● 3 secs after callscreens
comes. (bug attention-
● Screen is off.
Visibility mgmt. (III)
● Active app with audio of normal channel
● Inline web activity caller
● window.open(‘’, ‘’, ‘dialog’) opener
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.
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!
Orientation mgmt. (IV)
● 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.
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.
System wide UI
1. Dialog which not belong to a single app but
needs to fit app layout when some events
○ Volume warning dialog
○ SIM PIN unlock dialog
○ Cell Broadcast dialog
2. UI affecting window behavior
○ Software home button
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.
● Another hardware home button alternative.
○ While being enabled, swiped from bottom
could perform app closing.
● Automatically enabled on tablet.
(CE)Volume warning dialog
Show up while all of the following conditions
1. Earphone is plugged.
2. Exceeds volume threshold. ( > 85dB)
3. Content channel audio is playing.
4. First warning or after 20 consecutive hours
SIM PIN unlock dialog
Show up while
● The opening app has telephony permission
○ Blacklist: settings and FTU
● Airplane mode is turned off.
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 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.
● Creates a new
reference page to
provide the data to
● Reuse the existing
app window to
● Used to get your attention
○ Call screen - dialer
○ Alarm screen - clock
● Permission is necessary
● Only portrait primary orientation
● Non modal for now.
● Persona and mozPay API are using.
● Specific sizing: ~80%
● Partial visible homescreen during trustedUI
● 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
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)
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
○ 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.
FTU (First Time Usage)
● Launched via FTU ManifestURL setting.
● Only be launched automatically on fresh
○ make NOFTU=1 to avoid it.
● Way of app switching is disabled while FTU
Other special apps
○ Affect the size of active app window.
● Cost control
○ Widget-like iframe inside utility tray.
● Secure camera
○ Layout upon lockscreen.
○ Swappable app in the future.