1097457 - Input app launching and hardware.memory retrieval are asynchronous

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::System::Input Mgmt, defect)

Description

[John Lu [:mnjul][Please NI or I'll miss]]

Currently in input management (in KeyboardManager at current master or inputWindowManager after bug 1093537 lands), the launching of an inputApp and retrieving hardware memory are asynchronous in relationship with each other. Under extreme conditions, we could have manager.totalMemory = 0 when we are launching an inputApp (especially during tryLaunchOnBoot).

We should address this properly. For now, at bug 1093537, I'm putting a console.warn() if totalMemory is 0 when we launch an inputApp.

Comment 1

[John Lu [:mnjul][Please NI or I'll miss]]

I spent some time looking into this.

While it is quite trivial to make IWM._makeInputWindow dependent on the Promise used on retrieving navigator.getFeature('hardware.memory'), the subsequent propagation of asynchronousness would be troublesome -- especially in IWM.showInputWindow where IWM._currentWindow and IWM._lastWindow may need to be asynchronously set. As those two values play critical role in input management which are known to be frequently plagued by racing issues, this bug needs more thoughtful planning than originally expected.

On top of that, the asynchronousness actually only matters during boot since we need to retrieve the memory size only once, and I'm not sure if such (trivial but important?) use case can warrant the architecture change (that is, when we don't have bug 1112498 yet); or I need to think about a decoupled-but-reusable async+sync code paths and the async path is only used once.

Comment 2

[BMO Automation]

Firefox OS is not being worked on