Messaging App - Scroll to bottom and mark as read automatically

Evening bubblers,

I’ve been working on a chat-like feature for an app, and I have come into a couple issues. I’ve been googling around for examples of other chat apps, and have the basic functionality working. My app can send and receive chats, and has them displayed in a chat-like structure with the most recent message at the bottom. However, I can’t seem to find any information on a couple specific things.

  1. I use the repeating group scroll to bottom action on page load and on sending a message to scroll to the repeating group’s last entry. The repeating group uses vertical scrolling so that it can be embedded on a page with other information. I use a multiline input for chat messages, since multi-line messages are going to be needed. However, what I have noticed is that if chat messages do have multiple lines, the repeating group scroll doesn’t scroll all the way to the bottom. Changing the offset doesn’t seem to do anything. My hunch on this is that multi-line messages expand the height of the repeating group cell, and this causes the repeating group to be wrong in its offset calculation.

  2. I can’t seem to figure out how to trigger messages as “read” when their cell has come into view. I would even settle for marking them all as read when the repeating group is scrolled to the bottom and the newest message is visible, but I can’t seem to figure out how to do that either. All the examples online seem to use a button press, which I consider to be bad user experience.

If anyone has any insight on these, I’d appreciate it!


Scroll to entry -> Repeating group list of (datatype):count

In workflows click add new action -> when condition is true > repeating group is visible. Make changes to messages:last item -> read = yes

If your repeating group is full list style you can put a transparent element like an input box that’s disabled Below the repeating group and do

On page load -> scroll to element (transparent element)

1 Like

Hi Chris,

Perhaps I wasn’t super clear in my question. Currently I have an action that uses “Scroll to entry -> Repeating group list of (datatype):last item” and it’s causing it to not fully scroll down as the multi-line text seems to increase the cell height dynamically. Using “Scroll to entry -> Repeating group list of (datatype):item # Repeating Group list of (datatype):count” does the same thing, and this is as close to your suggested solution as I could get without bubble causing an error.

For your second suggestion, wouldn’t that just mark them as read if the repeating group itself is visible? In my implementation, the repeating group is set to “vertical scrolling”. What if there were new messages at the bottom of the repeating group that were out of view and unread? I wouldn’t want them to be marked as unread if they haven’t been seen by the user yet.

To show the behavior, here is a screenshot:

This is what is shown after the scroll to entry action has been called.

can you share an edit link?

I’m not comfortable sharing an edit link to the live app, but the good news is that when I was attempting to recreate the issue in a test app to share, I discovered that the error didn’t exist there. That led me to discover that the issue seems to be caused by the groups I have in the repeating group cell. I have one for left messages and one for right, as you can see in the screenshot. These groups are hidden or shown based on who the message is sent by.

For anyone who encounters a similar issue, what worked for me was setting the “collapse height on hidden” parameter on each group.

I’m still curious if anyone has a solution to 2 though.

Hi Austin,

The trick for number 2 is to create a list of users read. Essentially every time a user submits a new text it clears the list of users read (except adding the current user to the list). Then when the unread user clicks on the page it moves them to the users read list.

Hi Zach,

I get the concept of how to mark messages as read, what I’m having trouble with is how to trigger that functionality. It’s quite possible that a person loading a page could not see certain unread messages due to page scroll (or if they’re reading messages further up in the conversation when it comes in). I’m trying to figure out if there’s a way to trigger this if a specific message comes into the user’s view, or if the repeating group is scrolled past/to a certain message.

you mean something like this?

Ok, in answer to my own question “But how I can set up an event listener to scroll to the ‘last item’ when a new message is added to the repeating group of messages remotely (by another user)?”

This is looking like it works:

  • Create a custom state attached to the repeating group of messages. Custom state should be a number. It will track the ‘count’ of messages in the chatbox (aka repeating group of messages)

  • Create a workflow event that fires when page is loaded (Click here to add an event… > General > Page is loaded). It should (1) scroll to ‘last item’ of chatbox, then (2) set the custom state described above to number of messages in the chatbox.

  • Create another workflow event (Click here to add an event… > General > Do when condition is true). Edit the “Only when” setting to fire only when the ‘count’ of the chatbox (aka the repeating group’s messages count) is greater than custom state’s count (aka when another message is added to the conversation). There are 2 steps in this workflow event: (1) scroll to ‘last item’ of repeating group and (2) set state to (newly updated) ‘count’ of messages.


Thank you! I’m marking this as the solution, as it seems to mostly accomplish the goal. It’s a shame bubble doesn’t allow us more fine-grained control over the elements of a repeating group though. I could think of a number of uses for thing such as “when a repeating group element is _____”, “when a repeating group’s scroll position is 0/end/at item #”, or even just simple access to elements within a repeating group (such as accessing the RG item list of a nested RG).

This topic was automatically closed after 70 days. New replies are no longer allowed.