We've made various attempts to ensure that when we anchor the chat to the present that it remains there and remains a constant feed of current chat. When an image or video is placed into the chat it will take a short time to render and thus expand. This expansion changes the location of the chat buffer and we immediately start falling behind the current chat and the "jump to present' button spawns"
Expected Behavior: Chat should remain anchored at the bottom even if images and embeds render and change the spacing between chat lines.
We've made various attempts to ensure that when we anchor the chat to the present that it remains there and remains a constant feed of current chat. When an image or video is placed into the chat it will take a short time to render and thus expand. This expansion changes the location of the chat buffer and we immediately start falling behind the current chat and the "jump to present' button spawns"
Expected Behavior: Chat should remain anchored at the bottom even if images and embeds render and change the spacing between chat lines.
Three things were changing the height of the log after it was drawn, and only
one of the two cases anybody reads in was putting it back.
A picture with no measurements had no box. Where a service sends
dimensions — Discord, Matrix — the space was already reserved, and that is why
this was worst on Sneedchat: every embed there comes from a link the message
merely contains, so there were no dimensions and the row was nothing at all
until the image decoded, at which point it was three hundred pixels. On a
channel where most messages are pictures that is not an occasional jolt. An
unmeasured picture now gets a shape to sit in and measures itself on load, so
the change is box-to-box rather than nothing-to-something.
The drawn tail was sliding. The log builds a tail of rows rather than all
of them, so a message arriving pushed one off the top — which while you are
away from the bottom is the ground moving under you, and can unmount the row
you are reading. It grows instead of sliding now while you are away, and goes
back to a tail when you return to the present.
And the observer only helped when pinned — see #144, fixed in the same
commit.
One honest note: I could not reproduce the jump-to-present button appearing,
even with a 700px embed dropped in at your window size — the pin recovered
every time I forced it. What I could measure and fix is the mechanism
underneath it, the height spikes that make it possible. So this is
well-founded but its headline symptom is unconfirmed by me; if you still see
the button spawn on the new build, reopen and say what was on screen.
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
Three things were changing the height of the log after it was drawn, and only
one of the two cases anybody reads in was putting it back.
**A picture with no measurements had no box.** Where a service sends
dimensions — Discord, Matrix — the space was already reserved, and that is why
this was worst on Sneedchat: every embed there comes from a link the message
merely contains, so there were no dimensions and the row was *nothing at all*
until the image decoded, at which point it was three hundred pixels. On a
channel where most messages are pictures that is not an occasional jolt. An
unmeasured picture now gets a shape to sit in and measures itself on load, so
the change is box-to-box rather than nothing-to-something.
**The drawn tail was sliding.** The log builds a tail of rows rather than all
of them, so a message arriving pushed one off the top — which while you are
away from the bottom is the ground moving under you, and can unmount the row
you are reading. It grows instead of sliding now while you are away, and goes
back to a tail when you return to the present.
**And the observer only helped when pinned** — see #144, fixed in the same
commit.
One honest note: I could not reproduce the jump-to-present button appearing,
even with a 700px embed dropped in at your window size — the pin recovered
every time I forced it. What I could measure and fix is the mechanism
underneath it, the height spikes that make it possible. So this is
well-founded but its headline symptom is unconfirmed by me; if you still see
the button spawn on the new build, reopen and say what was on screen.
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.
We've made various attempts to ensure that when we anchor the chat to the present that it remains there and remains a constant feed of current chat. When an image or video is placed into the chat it will take a short time to render and thus expand. This expansion changes the location of the chat buffer and we immediately start falling behind the current chat and the "jump to present' button spawns"
Expected Behavior: Chat should remain anchored at the bottom even if images and embeds render and change the spacing between chat lines.
Finished - https://git.salastil.com/Salastil/moho/commit/7d5e377
Three things were changing the height of the log after it was drawn, and only
one of the two cases anybody reads in was putting it back.
A picture with no measurements had no box. Where a service sends
dimensions — Discord, Matrix — the space was already reserved, and that is why
this was worst on Sneedchat: every embed there comes from a link the message
merely contains, so there were no dimensions and the row was nothing at all
until the image decoded, at which point it was three hundred pixels. On a
channel where most messages are pictures that is not an occasional jolt. An
unmeasured picture now gets a shape to sit in and measures itself on load, so
the change is box-to-box rather than nothing-to-something.
The drawn tail was sliding. The log builds a tail of rows rather than all
of them, so a message arriving pushed one off the top — which while you are
away from the bottom is the ground moving under you, and can unmount the row
you are reading. It grows instead of sliding now while you are away, and goes
back to a tail when you return to the present.
And the observer only helped when pinned — see #144, fixed in the same
commit.
One honest note: I could not reproduce the jump-to-present button appearing,
even with a 700px embed dropped in at your window size — the pin recovered
every time I forced it. What I could measure and fix is the mechanism
underneath it, the height spikes that make it possible. So this is
well-founded but its headline symptom is unconfirmed by me; if you still see
the button spawn on the new build, reopen and say what was on screen.
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.