-
Notifications
You must be signed in to change notification settings - Fork 873
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
aichat: scroll is interruptable #21235
Conversation
A Storybook has been deployed to preview UI for the latest push |
a530c67
to
44614e0
Compare
A Storybook has been deployed to preview UI for the latest push |
A Storybook has been deployed to preview UI for the latest push |
A Storybook has been deployed to preview UI for the latest push |
c2b2e31
to
f021ca3
Compare
A Storybook has been deployed to preview UI for the latest push |
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.
It isn't auto-scrolling the user message anymore. So when I press enter on my message, I don't see it until a couple seconds later when the AI response starts being received.
f021ca3
to
1c22956
Compare
A Storybook has been deployed to preview UI for the latest push |
return | ||
} | ||
|
||
if (scrollPos.current.isAtBottom) { |
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.
Why can't we just here check if scrollerElement
is at the bottom and not need to have handleScroll
and scrollPos
?
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 did try that initially, but it looks like there's a timing issue. basically, computing isAtBottom
in the same call stack is flawed. additionally, it doesn't monitor when the user has scrolled to the bottom, which we need for auto scrolling behavior.
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.
Well, perhaps we can overcome the potential performance issue another way then. I'm seeing handleScroll called on every scroll when it's not neccessary until the content of the "last element" changes.
I'm assuming your issue when you tried this initially is because handleLastElementHeightChange
is called immediately when the content of the react properties change but before they are rendered (and definitely before the html layout is done). So couldn't that be fixed with a requestAnimationFrame
?
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 have also tried using rAF
to sync with browser's rendering within the same callstack. however, we are still off.
still, this approach doesn't resolve the need to continuously monitor the user's scroll while the generation is occurring. if the user decides to scroll back to the bottom, we need to switch back to the scroll-to-bottom behavior.
i agree that handleScroll
doesn't really need to be called on every tick. we can overcome this issue by throttling?
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, throttle at the very least. Or useLayoutEffect
?
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.
actually, we do need to monitor every tick. throttling can be unreliable because if the user is scrolling towards the bottom, it may compute positions at a later time, potentially missing the opportunity to autoscroll.
we could run the scroll handler in rAF
and make it tick with the monitor's refresh rate. ex. https://codepen.io/dcorb/pen/pgOKKw - potentially lowers the number of ticks compared to before but not significantly as throttling (depends on how limit).
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.
another idea: what if we run or attach the scroll handler only if context.isGenerating
? this satisfies the need to avoid unnecessary ticking and computing positions in a separate call stack.
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.
changed to only monitor when it's generating
1c22956
to
324eada
Compare
A Storybook has been deployed to preview UI for the latest push |
324eada
to
ff91d0a
Compare
A Storybook has been deployed to preview UI for the latest push |
A Storybook has been deployed to preview UI for the latest push |
f4ec482
to
8b82674
Compare
A Storybook has been deployed to preview UI for the latest push |
@@ -85,6 +89,23 @@ function Main() { | |||
} | |||
} | |||
|
|||
const handleScroll = (e: React.UIEvent<HTMLDivElement>) => { | |||
// Monitor scroll positions only when Assistant is generating | |||
if (!context.isGenerating) return |
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.
nit: please don't put return
on same line
Verified
|
* Merge pull request #21134 from brave/cr121 Upgrade from Chromium 120 to Chromium 121. * Remove the assert for patch_ffmpeg.py (#21184) * Merge pull request #21539 from brave/ffmpeg-dynamic-alloc Use dynamic allocation for ffmpeg fft tables on Windows. * Merge pull request #21585 from brave/issues/35318 Remove dynamic allocation of ffmpeg ff_tx tables. * Disables a flaky upstream browser test. * Merge pull request #21584 from brave/fix_new_tab_button_plus_misaligned Fixed new tab button's plus icon is mis-aligned with horizontal tab * Merge pull request #21600 from brave/121.0.6167.75_master Upgrade from Chromium 121.0.6167.57 to Chromium 121.0.6167.75. * Merge pull request #21628 from brave/maxk-disable-reading-mode Hides `Open in Reading Mode` context menu item. * [Uplift 1.62.x] AI chat issues cr121 1.62.x (#21629) * aichat: input is growable (#21124) * aichat: scroll is interruptable (#21235) * aichat: model maker text shouldnt look like a link (#21220) * aichat: code formatting (#21342) * make claude output formatted code (#21599) --------- Co-authored-by: Mikhail <matuchin@brave.com> Co-authored-by: Aleksey Khoroshilov <5928869+goodov@users.noreply.github.com> Co-authored-by: Simon Hong <shong@brave.com> Co-authored-by: taher <8665427+nullhook@users.noreply.github.com>
Resolves brave/brave-browser#32970
This PR allows user to interrupts the autoscroll while an answer is being generated. Additionally, it will resume back to autoscroll if the user's scroll is near the bottom.
Submitter Checklist:
QA/Yes
orQA/No
;release-notes/include
orrelease-notes/exclude
;OS/...
) to the associated issuenpm run test -- brave_browser_tests
,npm run test -- brave_unit_tests
wikinpm run lint
,npm run presubmit
wiki,npm run gn_check
,npm run tslint
git rebase master
(if needed)Reviewer Checklist:
gn
After-merge Checklist:
changes has landed on
Test Plan: