-
Notifications
You must be signed in to change notification settings - Fork 3.4k
feat(interaction): added service to detect last interaction #7965
Conversation
// the `onInput` function multiple times. | ||
timer = $timeout(function() { | ||
buffer = false; | ||
}, 650); |
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.
- is this timeout need to happen only if touchstart is being listened
- have we already talked about the 650 timeout? why 650? there's no way to avoid that?
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.
- Yes this is only needed for the touch event.
- Yes, we already talked about that.
The650ms
are coming from Patrick H. Lauke (W3C)
300ms is causing iOS (which has default delay of ~350ms) to trigger touch, then mouse (once mouse compatibility events fire). through trial and error (on iPhone 6S) a value of around 650ms seems more appropriate (and still snappier than the original 1s from previous version)
No there is no way, to avoid that.
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.
I don't think this timeout needs to trigger a digest.
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.
That is a good catch @crisbeto Thanks!
}, 650); | ||
} | ||
|
||
body.on('keydown', onInput); |
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.
This is pretty nitpicky and probably down to preference, but you can combine the calls like body.on('keydown mouseenter ' + mouseEvent, onInput);
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.
That works too, but listing those events in order is more clear here.
Apart from that digest on the |
e9faf66
to
12f7f0f
Compare
@crisbeto Thanks for the review. @ThomasBurleson @EladBezalel PTAL. |
Do ya'll expect this will resolve #7869 (comment) ? |
12f7f0f
to
7ea6489
Compare
@bradrich and @topherfangio to review. |
06b4345
to
8e8c6a6
Compare
Ping @bradrich and @topherfangio for review. |
This looks good to me. Quick question though (and this may be totally irrelevant), but your input map only handles Does this mean that if someone holds down a key, then presses a button with the mouse, then lets up the key Like I said, this may be totally irrelevant/probably not a case we need to worry about; just curious more than anything :-) |
@topherfangio Yeah this is valid.
But I don't think it's worth addressing this kind of edge-case, because the intention is just to provide proper accessibility -> If he doesn't trigger the element with a keyboard, the focus will be not restored. The only thing (the worst) which could happen is, that the focus will be restored incorrectly, due to a click while holding a keyboard press - I do not consider this as a big deal. I think the reason why we don't listen for the up events, is that we don't want to register too many listeners on the body element, because this is potentially performance damaging. Here is a package, which does the same
|
Cool; that's what I thought. LGTM 👍 |
This is a re-submit / rework of my old PR (#5589), should start from clean again.
Sample use-case:
Fixes #5563 Fixes #5434 Closes #5583