Obsolete
Status Update
Comments
hb...@gmail.com <hb...@gmail.com> #2
Please try to reproduce using the latest 4.4 emulator or device to see if this has already been fixed.
sh...@gmail.com <sh...@gmail.com> #3
About what happened from "onProcess(.) return FINISH_NOT_HANDLED" to "KeyEvent won't be dispatched"
1. onProcess returned FINISH_NOT_HANDLED;
2. InputStage apply function will call finish with handled value false;
3. in finish function q.mFlags will be set with QueuedInputEvent.FLAG_FINISHED;
4. then forward q;
5. then onDeliverToNext(q);;
6. for next stage is not null, next deliver is called;
7. for q.mFlags is QueuedInputEvent.FLAG_FINISHED, forward will be called, then deliver to next;
from now on, the rest stages' onProcess won't be called
Hope I analyze this rightly.
If I'm right, seems the logic is a little strange here:
Now we have two different situations: DISPATCH_HANDLED->FINISH_HANDLED->flag: FLAG_FINISHED&FLAG_FINISHED_HANDLED and DISPATCH_NOT_HANDLED->FINISH_NOT_HANDLED->flag: FLAG_FINISHED, I think if one of them should be meaning "I have finish my stage part work, and I think the event is finished handled, there is no need for the rest stages to handle it", that one should be DISPATCH_HANDLED->FINISH_HANDLED->flag: FLAG_FINISHED&FLAG_FINISHED_HANDLED
Maybe FLAG_FINISHED_HANDLED flag is the proper flag to judge whether the event should be forward in deliver function.
1. onProcess returned FINISH_NOT_HANDLED;
2. InputStage apply function will call finish with handled value false;
3. in finish function q.mFlags will be set with QueuedInputEvent.FLAG_FINISHED;
4. then forward q;
5. then onDeliverToNext(q);;
6. for next stage is not null, next deliver is called;
7. for q.mFlags is QueuedInputEvent.FLAG_FINISHED, forward will be called, then deliver to next;
from now on, the rest stages' onProcess won't be called
Hope I analyze this rightly.
If I'm right, seems the logic is a little strange here:
Now we have two different situations: DISPATCH_HANDLED->FINISH_HANDLED->flag: FLAG_FINISHED&FLAG_FINISHED_HANDLED and DISPATCH_NOT_HANDLED->FINISH_NOT_HANDLED->flag: FLAG_FINISHED, I think if one of them should be meaning "I have finish my stage part work, and I think the event is finished handled, there is no need for the rest stages to handle it", that one should be DISPATCH_HANDLED->FINISH_HANDLED->flag: FLAG_FINISHED&FLAG_FINISHED_HANDLED
Maybe FLAG_FINISHED_HANDLED flag is the proper flag to judge whether the event should be forward in deliver function.
al...@android.com <al...@android.com>
go...@gmail.com <go...@gmail.com> #4
I remember I encountered the same issue on Android 4.3.
I fixed that but it is a long time I do not remember the details.
Does anyone know how AOSP fixes it?
I fixed that but it is a long time I do not remember the details.
Does anyone know how AOSP fixes it?
go...@gmail.com <go...@gmail.com> #5
I searched with the keyword "mCurMethod" in gerrit and seems to find the related changes to fix it.
It is the commit.
https://android-review.googlesource.com/c/platform/frameworks/base/+/68103
But IMHO, it is not merged into master because of merge conflicts.
Can we discuss with this bug a little bit?
It is the commit.
But IMHO, it is not merged into master because of merge conflicts.
Can we discuss with this bug a little bit?
Description
Is this an issue? If not, why?
Android 4.3 code:
When there is no active method, mCurMethod of InputMethodManager is null
->
InputMethodManager.java
dispatchInputEvent(...) return ViewRootImpl.EVENT_POST_IME when mCurMethod == null;
so
ViewRootImpl.java
class ImeInputStage
onProcess(.) return FINISH_NOT_HANDLED
Result to KeyEvent won't be dispatched.