Closed Bug 1097457 Opened 8 years ago Closed 5 years ago

Input app launching and hardware.memory retrieval are asynchronous

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: mnjul, Unassigned)

References

Details

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
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.