Likely related to: #143 when we're viewing the past and the "jump to present" button is visible we continue scrolling upward.
Expected behavior: No movement of the chat buffer when we're viewing past messages.
Likely related to: https://git.salastil.com/Salastil/moho/issues/143 when we're viewing the past and the "jump to present" button is visible we continue scrolling upward.
Expected behavior: No movement of the chat buffer when we're viewing past messages.
Nothing was holding your place. The resize observer put the view back when
pinned to the bottom and did nothing otherwise — while the scroller sets overflow-anchor: none, which is us telling the browser not to do it either.
So an image loading three hundred lines back moved you, and neither we nor
Chromium was going to move you back. The row at the top of the view is now
noted as you scroll and put back where it was after anything resizes.
And the window of drawn rows was sliding off you as new messages arrived,
which moves the content upward past you — which is exactly the direction
reported here. See #143 for that half.
Verified by growing 400px above a parked reader: before, they moved the full
400px; after, the row at the top of the view was still at the same pixel.
Measured against live #fishtank in the configuration this was reported from
— window in a split pane, member list open, message column 254px wide:
60s pinned to the bottom: 0 of 120 samples off the bottom, worst gap 0px,
jump-to-present never appeared
45s parked in the past: the log grew 661px underneath, and the row at the
top of the view did not move once
Before, the same tests showed gaps of 320–600px while pinned, and a synthetic
400px growth above the reader moved them the full 400.
Finished - https://git.salastil.com/Salastil/moho/commit/7d5e377
The cause was two-fold and both halves are fixed.
**Nothing was holding your place.** The resize observer put the view back when
pinned to the bottom and did nothing otherwise — while the scroller sets
`overflow-anchor: none`, which is us telling the browser not to do it either.
So an image loading three hundred lines back moved you, and neither we nor
Chromium was going to move you back. The row at the top of the view is now
noted as you scroll and put back where it was after anything resizes.
**And the window of drawn rows was sliding off you** as new messages arrived,
which moves the content upward past you — which is exactly the direction
reported here. See #143 for that half.
Verified by growing 400px above a parked reader: before, they moved the full
400px; after, the row at the top of the view was still at the same pixel.
Measured against live `#fishtank` in the configuration this was reported from
— window in a split pane, member list open, message column 254px wide:
```
60s pinned to the bottom: 0 of 120 samples off the bottom, worst gap 0px,
jump-to-present never appeared
45s parked in the past: the log grew 661px underneath, and the row at the
top of the view did not move once
```
Before, the same tests showed gaps of 320–600px while pinned, and a synthetic
400px growth above the reader moved them the full 400.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Likely related to: #143 when we're viewing the past and the "jump to present" button is visible we continue scrolling upward.
Expected behavior: No movement of the chat buffer when we're viewing past messages.
Finished - https://git.salastil.com/Salastil/moho/commit/7d5e377
The cause was two-fold and both halves are fixed.
Nothing was holding your place. The resize observer put the view back when
pinned to the bottom and did nothing otherwise — while the scroller sets
overflow-anchor: none, which is us telling the browser not to do it either.So an image loading three hundred lines back moved you, and neither we nor
Chromium was going to move you back. The row at the top of the view is now
noted as you scroll and put back where it was after anything resizes.
And the window of drawn rows was sliding off you as new messages arrived,
which moves the content upward past you — which is exactly the direction
reported here. See #143 for that half.
Verified by growing 400px above a parked reader: before, they moved the full
400px; after, the row at the top of the view was still at the same pixel.
Measured against live
#fishtankin the configuration this was reported from— window in a split pane, member list open, message column 254px wide:
Before, the same tests showed gaps of 320–600px while pinned, and a synthetic
400px growth above the reader moved them the full 400.