Is this meant to happen? Does `Modifier.verticalSc...

# compose

[Alex Styl]

Is this meant to happen? Does Modifier.verticalScroll() consume clicks normally?

Box {
    Box(Modifier.fillMaxSize().clickable { warnln { "Click!" } }) // <- never gets clicked
    Box(Modifier.fillMaxSize().verticalScroll(rememberScrollState()))
}

[Alex Styl]

I can imagine why it might be intended, but it's weird from an dev POV.

Ended up working around it by making the scrollable's content clickable instead and treat it as my bg

[Nitesh Singh]

what is meaning of POV

[Konstantin Klassen]

Point of view

[Ashu]

both use fillMaxSize(). Since they stack, the scrollable Box is on top, preventing clicks from reaching the clickable Box. i think !!

[Louis Pullen-Freilich [G]]

This is because pointer input events aren’t shared with siblings. If you flip the order of the modifiers / boxes, then the other modifier would receive all events - it’s not about the specific modifier’s behavior. If you moved one of the modifiers to be on the parent box instead of a sibling it should resolve it also

[Alex Styl]

it’s not about the specific modifier’s behavior

I'm confused. If that's not the case why does this gets clicked?

Box {
                Box(Modifier.fillMaxSize().clickable { warnln { "Click!" } }) // <- gets clicked
                Box(Modifier.fillMaxSize())
            }

[Louis Pullen-Freilich [G]]

I meant that any pointerInput modifier should have the same effect

[Louis Pullen-Freilich [G]]

So if you just add an empty pointerInput() modifier on the second box, or clickable, or scrollable, etc

[Alex Styl]

ah gotcha. are u saying that the verticalScroll uses pointerInput() and as a result it doesnt share the event with the siblings?

[Louis Pullen-Freilich [G]]

yeah exactly. The simplest case is just:

Box {
    Box(Modifier.pointerInput())
    Box(Modifier.pointerInput())
}

By default, only one of these can receive any events

[Alex Styl]

This somewhat makes sense. I know that you can consume events like this:

Modifier.pointerInput(Unit) {
    awaitPointerEventScope {
        while (true) {
            val event = awaitPointerEvent(
                pass = PointerEventPass.Main
            )

            event.changes.forEach { it.consume() }
        }
    }
}

If just setting the pointerInput() consumes the event, why is there a way to consume changes? is that a different thing?

[Louis Pullen-Freilich [G]]

It’s a bit different, the case I mentioned is just for siblings - and often you cannot control the hierarchy in this way from a component so you can’t really use that meaningfully. Also, the order of siblings matters, so if you change the order then the sibling that receives the event changes

[Louis Pullen-Freilich [G]]

Consuming events is for a parent - child relationship, you can consume events to let other pointer input nodes know that you have already used this event, and they shouldn’t look at it

[Alex Styl]

perfect. that clarified things. thanks Louis

[Konstantin Klassen]

For the parent-child propagation, https://developer.android.com/develop/ui/compose/touch-input/pointer-input/understand-gestures might be interesting, especially the "touchSlop" part which helps to decide if the user scrolls or just clicks