-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Verify event is not null on touch.js #13
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yay, great catch!
app.sendEvent_(event); | ||
} finally { | ||
pool.release(); | ||
if (event !== null) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh wait, sorry, I'm not sure I understand what happens here. Does -[UIApplication _touchesEvent]
keep returning nil
or is it a random glitch? If it's the latter I'm wondering if we should make the _touchesEvent()
call earlier, before we do pending.shift()
, and simply return there -- that way dispatchTouch:
gets called again on the next frame, and might succeed that time and keep going. (But if this is a permanent failure, I suppose we should call onComplete()
with an Error
so it can reject the Promise
?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It occurs when the application goes to the background for any reason and comes back. So I would say it's happening on a non-predictable manner.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting. I guess the tap down event instantly triggers backgrounding, and in this failure case we get the next dispatchTouch:
just after the app has gone off screen -- whereas in the happy case we get it after it is back on the screen again.
If that is correct, I think we have two options:
- Keep trying, by returning early, before we do
pending.shift()
. In this way we will eventually move it through the different phases. - Complete the touch right away, as if
pending.length === 0
. In that case we will have to releasepriv.touch
if we already created it.
It seems to me that 1) is the right solution, since we will keep going once the app is back on the screen. This is also what happens when we are luckier -- the app goes to the background and dispatchTouch:
does not get called until it's back on the screen.
What do you think, @mrmacete?
No description provided.