FirefoxOS/Stingray/Focus-Manager

bug 1136589 focus fallback

What's the Problem

Smart system app in Stingray project is a fork of phone's system app. It inherits all features and issues from system apps. In recently models of phone, we do not have hardware keyboard support, including built-in hardware keyboard, USB keyboard, BT keyboard, additional keys for other purpose. The focus is only transferred by touch. If we have focus issues in system app, we cannot found it because the focus will be transferred back to correct element when user touch it.

Smart system app is running at a multiple input devices environment, including touch, mouse, keyboard, etc. If we have focus issues in smart system app, it breaks features in keyboard.

Focus Issues

The focus issues we current found are:

1. bug 1125036 We don't have a way to know why focus transferred is failed in Gecko.
2. We are trying to focus non-operable element.
3. We don't switch focus while some system UI shows up
4. We use HTMLDOMElement.focus() in many places, including system UI and app window, and they give us race condition.

System UIs in smart system are places with a lot of focus issues. Smart system app forgets to set focus in most of them, item 3. In some of them, we found issue 2 and issue 4.

Focus Manager: bug 1136590, bug 1139314

Focus Manager is a single place which handles focus requests and helps other modules to decide which UI should be focused. There are two pars in Focus Manager: doing focus staffs and auto-fix focus while it finds focus issue.

There are three different types of UI in smart system:

1. System UI: This is a system overlay managed by smart system app, like sleep menu, trusted UI, captive portal, etc.
2. AppWindow: This is a core of smart system app which holds the app iframe.
3. App Wide UI: This is a supporting UI for app iframe, like context menu, app's alert, confirm, prompt dialogs, HTTP login dialog, etc.

Since the focus in AppWindow and App Wide UI had been managed pretty well, we only focus on System UI in Focus Manager. But we still have issue 4 in smart system app. AppWindow and App Wide UI should migrate to use Focus Manager to focus itself in the future.

Focusable UI

Focus Manager maintains a UI list. All UIs, including system UI and AppWindow, can use addUI/remoteUI to be in UI list. Once a module's UI is added to DOM, we should add this module to Focus Manager so that it can calculate the top most UI. And once a module's UI is removed from DOM, we should remove this module from Focus Manager but this is optional because we can use isVisibile() API to check if the UI is visible.

A module who wants to get focus should implement three APIs:

• isVisibile(): returns a boolean to tell it is visibile or not.
• getElement(): returns a HTMLDOMElement for top-most UI calculation. We will return the container of this UI basically. It still works if you return any HTMLDOMElements inside of container.
• focus(): calls HTMLDOMElement.focus() on the element you want to focus.

To Focus Top-Most System UI

The focus procedures are:

1. setTimeout(): please refer to comment 4, 9, and 13 in bug 1113592 for the main reason.
2. Calculate top-most UI
3. Focus UI or App Window

Calculate Top-Most UI

The procedure to calculate top-most UI are:

The LCA in this chart is least common ancestor. The Get LCA Nodes is to get ancestors which is direct under LCA. We have to use LCA to find the comparable nodes because all UIs in system may not at the same container.

Auto-fix Focus Issue

Focus Manager listens the following events and check if we have focus issue:

• keydown
• keyup
• mozbrowserbeforekeydown
• mozbrowserbeforekeyup

Once Focus Manager found the focus issue, it calls focus() method to re-focus the correct UI. In smart screen, we enable this feature by default. We may disable this feature once we fix all the focus issue.

Detect Focus Issue

The following cases are viewed as focus issue:

1. document.activeElement is HTML or BODY
2. document.activeElement's css display is none or css visibility is hidden
3. One of ancestors of document.activeElement has css display: none or css visibility: hidden

Overheads

Focus Manager needs to know the css display and css visibility of a specific element. So, it uses window.getComputedStyle(HTMLDOMElement) to force reflow.