Closed Bug 1097457 Opened 10 years ago Closed 6 years ago

Input app launching and hardware.memory retrieval are asynchronous


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

Gonk (Firefox OS)
Not set


(Not tracked)



(Reporter: mnjul, Unassigned)



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.
See Also: → 1093537
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.
Firefox OS is not being worked on
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.