Why to merge TV system into phone system

There are so many duplicated modules in both system. For long-term maintenance, we should merge them into a single system.

Difference between two system apps

Please find the detailed information at this slide.

Merge plan (meta: bug 1147250)

It consumes a lot of resource to merge system apps in one step. We set them into four phases:

1. Modules can be disabled on demand (meta: bug 1155018)
2. TV specific window manager is created and can be loaded on demand (meta: bug 1179642)
3. TV visuals are created and can be loaded on demand (meta: bug 1154191, TV system is switched at the end of this phase)
4. Build script dynamic builds TV system app (meta: bug 1179648)

Modules can be disabled on demand (meta: bug 1155018)

In TV system app, we had disabled a lot of modules, like RIL, Edge Gesture, Rocketbar, etc. In this phase, we should follow the BaseModule, designed by alive, to disabled modules.

We already introduced the device type to system app, bug 1150423. The BaseModule should load different sub-modules based on the device type, bug 1156596. After bug 1156596 landed, we can check each module to decide if we should rewrite it as a BaseModule module. We should rewrite it as a BaseModule module when it has other dependencies, like Lockscreen.

TV specific window manager is created and can be loaded on demand (meta: bug 1179642)

The main difference between two system apps is window manager. This phase includes the focus issue ,bug 1154620, which is not fully considered. The window manager in current TV system app is not the latest design. We should follow the slide to implement Landing app, Homescreen app, and Default app separately.

The rules to implement the window manager:

1. We may split a single module into multiple sub-modules to implement them
2. We may overwrite the whole module to have TV specific behaviors

Some of focus should be fixed at next phase because they are belonged to visual specific issues. The focus issues who should be fixed at this phases are things related to window management, like focus lost while window switching, setting focus before window loaded, setting focus while animating, etc. Not all of issues are filed to bugzilla. We should file it and fix it at this phase as more as possible.

The rules to set focus correctly are:

1. We should blur the activeElement if it is iframe before setting a focus to another element, see the finding at bug 1113592 comment 9.
2. We should prevent focus switching while user presses a key, bug 552255.
3. We should set focus after an iframe is loaded.
4. We should move focus to a inactive state which consumes all key events while animation is running. For cases that we may want to cancel the animation, we don't need to do so.
5. We should move focus while setting an element into inactive state, like parent.removeChild(child), disabled=true, display: none, visibility: hidden, etc.
6. We should not call HTMLDOMElement.focus() while setting focus but call a module, Service.request('focus', [your module]) , to find out the top-most UI and set focus to it.
7. Unknown rule 1, bug 1169578.

TV visuals are created and can be loaded on demand (meta: bug 1154191)

TV has its owned visuals. Most of them are implemented with web component at gaia-components and smart-components repos. Before creating TV visual, we should consider if the visual is a generic component. If yes, we should implement it in web component.

Whiling implementing visuals, we may need to split a module into visual part and logic part. That helps us to swap visual dynamically.

After this step, we may have all TV features at phone's system. We switch the system app from tv_apps/smart-system to apps/system at this phase. Everything may be fine with phone's system, except the load time. It would be nice to retest the load time, bug 1155128, at this phase. To have a fair comparison, we suggest to test the load time at real TV set which may need helps from partners.

Build script dynamic builds TV system app (meta: bug 1179648)

Before this phase, everything is configured at run-time. That's not enough. We should let build script have the ability to copy, remove, or modify files at build time. In our plan, build script parses files to find the dependencies from SUB-MODULES. With that, build script also needs to refer to the legacy dependencies map which is for non-BaseModule modules. With all of them, build script can decide which JavaScript files are required.

Besides JavaScript files, we also need to do similar thing to CSS files, images, and other resources.