mozilla :: #apz

13 May 2017
01:27rhuntbotond: ah yes I can see the need for that. I was thinking of a model of whenever there is a potential focus changing event (like a key that doesn't have a scroll action like a tab) we disable until the next repaint
01:27rhuntbotond: but the problem with that I think is that a repaint might not be updated as far as the latest event
01:28rhuntbotond: we could only really be sure with a seq number approach, which makes sense
01:28botond|homerhunt: yup, exactly
01:31botond|homerhunt: you might be able to reuse the "input block id" for the sequence number
01:31botond|homerhunt: or, even if not, plumb it through the same channels (e.g. InputAPZContext)
01:35rhuntbotond: ah interesting, yeah I'll take a look at that. What is input block ID normally used for?
01:36rhuntbotond: and yes I don't believe it's possible for KeyboardActionMap to change after startup but I'll need to confirm that
01:37botond|homerhunt: APZ sometimes waits on one or two confirmations from content before proceeding to process an input block (the "i'm not going to preventDefault() this" confirmation, and the "this event really is targeting this scroll frame" confirmation)
01:38botond|homerbarker: the input block id is used by APZ to identify the input block the confirmation pertains to
01:38botond|homerbarker: it's assigned by APZ, and sent along with the event to content
01:38botond|homewhoops, didn't mean to ping rbarker :)
01:39botond|homerhunt: so, as long as the granularity of "one per input block" is fine for the sequence numbers, we can just use the input block id
01:40botond|homerhunt: (if it's not fine, i.e. we need a different sequence number for each event even within an input block, then we can't reuse it, but we can send it through the same channels)
01:46rhuntbotond: ah that makes sense, what defines an input block? I was looking through that code and was a little confused with all the different kinds of input
01:46botond|homerhunt: yeah, there isn't really a unified definition, it depends on the input type
01:47botond|homerhunt: the closest i can think of a unified definition is, "the largest set of consecutive inputs for which we only need a single confirmation (of each kind, if applicable) from content"
01:48botond|homerhunt: so e.g. for touch events, every touch-start starts a new input block
01:49botond|homerhunt: for wheel events, consecutive wheel events go into the same block but mouse movement or a timeout "expires" the block
01:49botond|homerhunt: i'm not sure yet what the most sensible arrangement for keyboard events would be
01:50rhuntbotond: okay that makes sense, is there only one input block active at a time, and do they all share the same ID space?
01:51botond|homerhunt: they all share the same id space (see
01:52rhuntbotond: yeah I'm not sure what a good arrangement for that is, if we don't wait for a content response they're all kind of discrete events that don't need approval
01:52botond|homerhunt: i think for each input type, one input block can be active at a time
01:52botond|homerhunt: but you can also get input blocks queued up
01:53botond|homerhunt: so for example, if you do two touch pans, and by the time the second one starts we still haven't received the content response for the first
01:53botond|homerhunt: then the events of the second pan get queued into a second touch block, while the first is still waiting to be processed
14 May 2017
No messages
Last message: 130 days and 16 hours ago