ScrollBehaviorConfig with long texts

[bernd70]

Hi,

in my understanding ScrollBehaviorConfig solves the issue of multiple Agent responses scrolling outside the visible view. Like discussed in Issue #13.

In my particular case I have just one single long streaming answer and I want to stop autoscrolling as soon as the top of the Agents answer reaches the upper boundary of the parent view.

Is there a way to achieve this with the current version of the package? And if not, are you planning to implement this in the foreseeable future?

Best regards,
Bernd

[hooshyar]

Thanks for the detailed report — you found a real bug, not a missing feature.

ScrollBehaviorConfig.scrollToFirstResponseMessage: true was already meant to do exactly what you're asking for (autoscroll stops once the top of the AI response reaches the top of the viewport), but the internal implementation computed the scroll target from index / itemCount, which assumes every message is roughly the same height. With the common shape of one short question + one very long streaming answer, that assumption breaks badly — for the default reverse: true list it effectively collapsed to "just show the bottom", i.e. exactly the behavior you reported (the top of the answer keeps scrolling out of view as it streams).

Fixed on main (7022038): both scrollToMessage and forceScrollToFirstMessageInChain now measure the message's actual rendered position instead of estimating it, so this works correctly for a single long streaming message, not just multi-message response chains. No API changes — just set:

scrollBehaviorConfig: ScrollBehaviorConfig(
  scrollToFirstResponseMessage: true,
),

This will ship in the next release (tracking in #41). I'll update this thread when it's published to pub.dev.

[bernd70]

Glad you are working on that. Just tested it right now and it works in some way. The long AI answer fully scrolls to the end and when it is finished it jumps to the start.

This is not the behaviour I expected or wished for. I would prefer a pinning approach:

• I hit Go on my question
• The AI starts answering and the screen starts scrolling
• Now my question or the start of the AI's answer (should be definable) should not scroll out of the viewport. The conditional scroll to bottom button appears
• Now I can read the answer and scroll to end of the answer at my reading speed

Does this make sense to you?

Best regards

[hooshyar]

Yes, that makes complete sense — thanks for testing and for the clear description.

You're right that this isn't fully fixed yet. What shipped (7022038) corrected the targeting of an end-of-stream jump (a real, separate bug where the scroll position was computed from a broken heuristic), but that's not the same as what you're asking for. You want a live pin during streaming: the top of your question (or the start of the AI's answer — configurable) stays anchored at the top of the viewport for the whole duration of the response, with no scroll happening at all until you choose to (via the scroll-to-bottom button or your own scroll gesture). Right now the controller doesn't scroll at all while streaming (only once, at the end), which is why the answer's start silently scrolls out of view as it grows — exactly what you're seeing.

Plan:

1. Add a new ScrollBehaviorConfig option to pin an anchor (your question, or the response start) at the top of the viewport for the duration of a streaming response.
2. While pinned, the view holds that position as the answer grows underneath — no jump, ever, at the end.
3. The existing conditional scroll-to-bottom button appears once there's more content than fits; tapping it (or manually scrolling) releases the pin so you're back in full control, at your own reading speed.

I'll implement and test this, then reply here again with the version once it's out. No API changes to what you're already using — this will be additive.

[hooshyar]

Thanks for testing and for the precise description — that made it clear the first fix targeted the wrong moment. It scrolled back to the answer's first line after the stream finished; you want the pin to hold while it streams. That's now a real feature, shipped in v2.16.0 (on pub.dev now):

AiChatWidget(
  scrollBehaviorConfig: const ScrollBehaviorConfig(
    // responseStart: hold the first line of the answer at the top of the viewport
    // userMessage:   hold your own question there instead (Q + A read together)
    pinDuringStreaming: StreamingPinAnchor.responseStart,
  ),
  // ...
)

Behaviour, matching your list:

1. You hit Go — the list scrolls to your question as usual.
2. The answer starts streaming and the list follows it — until the anchor (answer start, or your question) reaches the top of the viewport.
3. From then on it's held there; new text arrives below the fold and the scroll-to-bottom button appears.
4. Any scroll gesture (drag / fling / mouse wheel) or a tap on the scroll-to-bottom button hands control back to you for the rest of that answer. In the default newest-at-bottom list the text you're reading also stays still while more chunks arrive, instead of being pushed upward.
5. When the stream ends nothing jumps.

The default stays StreamingPinAnchor.none (previous behaviour), so nothing changes unless you opt in. It works both when you flag updates with 'isStreaming': true and with the addStreamingMessage → updateMessage → stopStreamingMessage flow. There's a pin picker in the example app's "Streaming + Markdown" screen (AppBar pin icon) if you want to compare the three modes.

Could you give 2.16.0 a try and confirm it behaves the way you described? I'll close this once you're happy.

[hooshyar]

Quick update before you test, in case you haven't yet: if you were on 2.16.0, there was a same-day regression affecting exactly the flow this example app (and many real integrations) use — addStreamingMessage → updateMessage → stopStreamingMessage. The pin would arm correctly, then release itself a few hundred milliseconds later because of a delayed auto-scroll internally treating itself as "the reader took over." Fixed in 2.16.1, with a regression test that fails on 2.16.0 and passes now.

Current release is 2.16.2 (just published) — no further changes to the pin behavior itself, just this fix plus unrelated package polish. If you get a chance to try pinDuringStreaming: StreamingPinAnchor.responseStart (or .userMessage) on 2.16.2, I'd appreciate confirmation it now matches what you described. Happy to keep this open until you've had a chance to check.

[bernd70]

That was quick! Tried it just now with 2.16.2 using pinDuringStreaming: StreamingPinAnchor.responseStart and there are two issues:

1. It stops scrolling at the right position, but it appears it always scrolls a few pixels more than required and then resets / scrolls back to the correct position. So there is a kind of flickering. This is the same behaviour I achieved when I tried to fix it on my fork but gave up then. Also tried autoScrollBehavior: AutoScrollBehavior.never, with no change.
2. Although I use StreamingPinAnchor.responseStart, after the complete message is delivered it scrolls back to the beginning of the question.

Your updates are faster than me sending this message. Tried with 2.19.1 as well with no change.