1040603 - Queue the UserPress events

Status: RESOLVED DUPLICATE of bug 1145072

(Firefox OS Graveyard :: Gaia::Keyboard, defect)

Description

[Tim Guan-tin Chien [:timdream] (please needinfo)]

To make bug 1040548 work, UserPress event should be queued and handled only after the previous event is handled. This is the queue to implement before removing the queue in latin.js in bug 1040548.

I think we could use a Promise-based queue, but first we need a timing on when a previous task is considered complete.

I am think about allowing IMEngine to return a promise on selected methods (e.g. click() and select()) and wait for promise to resolve. For IMEngines w/o promise implemented (i.e. if the method returns something not then-able), we consider the next event can be pushed right away.

(There are some edge cases like composition keys which we basically call click() n-times -- we should remove that first.)

Comment 1

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Will take a look this week.

Comment 2

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Attachment: WIP

It ends up that I created an action queue instead of userPress queue, or otherwise we have to return promise from TargetHandlersManager to ActiveTargetManager and to UserPressManager.

Not sure if this is right way to go, but at least we could try the following behavior a bit,
  - keep key popup until the sendKey action is resolved.

Comment 3

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 8506818 [details] [review]
WIP

Looks good, please complete the patch here that

-- does not remove the queue in latin.js
-- does not change the timing of |visualHighlightManager.hide()|

We should do these two things later in another bug.

PS Your current patch didn't hide the popup at the proposed timing (it hides the popup at the time processing is complete + 75ms)

Comment 4

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Comment on attachment 8506818 [details] [review]
WIP

Tim,

Thanks for the advice, very helpful.
Patch updated to address your comments. 
Mind to give it a second look?

--
Also ask for Omega and Bruce to take a look as we discussed in the previous meeting.
Please be informed that right now I would still clear the highlighting effect when you press the next key or otherwise you would see multiple key popups on a slow device, which I think does not make sense.

Comment 5

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 8506818 [details] [review]
WIP

Not there yet.

Cancelling ui-review because this bug should not have UI changes.

Comment 6

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

The original approach proposed here has been taken to resolve bug 1145072.
So dupe this one to that, the follow-up should be bug 1040548.