IssueTracker

I gave it some thinking and my current inclination is that it doesn't make sense at all to make it a foundational requirement.

It's a grey areas, but still it strikes me as a design choice more than a general concept, so I wonder if we can just add delay(80) to our ripple logic to solve the issue, but allow other indication/design system devs to decide on their own.

Louis, wdyt?

This shouldn't be inside our Ripple, as it applies not only for this ripple. Plus once we migrate to the ripple imlementation based on RippleDrawable we would still need this delay. I think this should affect all indications

I agree, I think this is core touch slop behavior for Android - it doesn't matter what the indication type is, we probably just don't want to propagate the down event until we are sure it wont' be the start of a scroll event

Maybe it's reasonable to make this configurable (per platform?) but I don't think we should have any logic in indication / ripple at this level

We can utilize the ViewConfiguration that we have and that lives in commonMain for that. Would be great if we can somehow manage to incorporate it into the generic foundation indication then.

I don't like the idea of not propagating any events without any particular reason. It seems like the issue is with the indication, not the touch behaviour itself. The item should remain interactable and clickable even if click (down + up) fits into the 80msa or whatever timeframe we have for delaying the indication. Please, let me know if there are reasons why we would want to delay the pointer event itself.

Unless we have a strong reason, I'd like to keep this change localised in the indication api surface, not the touch surface. But I agree that generic foundation indication might be a better fit than ripples.

Folks, let me know what you think about it.

I don't like the idea of not propagating any events without any particular reason.

Sorry, my message was confusing. What I mean is propagating the PressInteraction inside clickable, etc. I think these components should wait before sending the interaction - the actual motion events should not be touched.

If I read View.java correctly, this is how it works in the framework as well:

// For views inside a scrolling container, delay the pressed feedback for
// a short period in case this is a scroll.
if (isInScrollingContainer) {
    mPrivateFlags |= PFLAG_PREPRESSED;
    if (mPendingCheckForTap == null) {
        mPendingCheckForTap = new CheckForTap();
    }
    mPendingCheckForTap.x = event.getX();
    mPendingCheckForTap.y = event.getY();
    postDelayed(mPendingCheckForTap, ViewConfiguration.getTapTimeout());
}

and

private final class CheckForTap implements Runnable {
    public float x;
    public float y;

    @Override
    public void run() {
        mPrivateFlags &= ~PFLAG_PREPRESSED;
        setPressed(true, x, y);
        final long delay =
            ViewConfiguration.getLongPressTimeout() - ViewConfiguration.getTapTimeout();
        checkForLongClick(delay, x, y, TOUCH_GESTURE_CLASSIFIED__CLASSIFICATION__LONG_PRESS);
    }
}

So setPressed() is only called after the delay, when inside a scrolling container.

Do we have any current metadata for 'in a scrolling container' (presumably we do in semantics somewhere?) - can we use this in a similar way? It doesn't makes sense to delay the indication when there is no scroll action

Thanks for checking, this rouse makes sense to me.

100% agree that we need to do it only in the scroll container -- that's a separate issue on it's own and I don't think semantics will help much here, but maybe?

talking out-loud: I was wondering if there's any reason other than indication when you want to delay the press interaction other than for the indication? probably if you long the event you can also want to not to have flakes when scrolling or similar, so it's the similar problem then.

And if we have ViewConfiguration, than you can always opt out specifically from the time out by providing a different ViewConfiguration in LocalViewConfiguration ambient

And if we have ViewConfiguration, than you can always opt out specifically from the time out by providing a different ViewConfiguration in LocalViewConfiguration ambient

Oh I didn't realize we already had a common abstraction here, nice - yeah this looks really flexible to me.

talking out-loud: I was wondering if there's any reason other than indication when you want to delay the press interaction other than for the indication?

Yeah I think every case that cares (indication, changing a button to appear pressed (like elevation), sending logging metrics to a server when it is pressed, etc) should have this delay - if a scroll happens in the timeout then we cancel the click, so I think this should not emit the PressInteraction as well

Good point, the same is probably true for clickable list items with a swipe to dismiss action as well (and similar) - anything where the parent or this layout can be dragged / swiped.

Back to Matvei to consider providing scrolling-container metadata so we can only enable this timeout if there could be a scroll / drag in the post 1.0 timeframe.

Filed b/203141462 to track only delaying if we are in a scrollable container, closing this bug because the original issue of no delay no longer exists.