Babble - A Chat Plugin

Line wrap seems to be hit and miss. One user who tried it was seeing correct line wrap as he typed, but after hitting return they were only partly visible. I thought this might be a result of having a particularly long user Name, but this was unrelated. Strangely, his posts started line wrapping correctly after 5 or so posts.

Could you create a github issue here with a screenshot of the unwanted behaviour?

Okay I’ve got a fix for this and will push with the next update.

We already have two completely separate sets of permissions for determining whether you can see a chat, one for groups and one for categories. It’s about at the edge of unwieldiness that I’d like to see. So I opted for re-using the existing group logic, rather than having to go down three paths to determine whether you can view / respond to a topic or not.


Did this ever get sorted?

Thanks, that makes sense :slight_smile:

Alright, I’ve been chipping away at some things today. Here’s a list of stuff I did:

  • Added individual user settings for disabling Babble and enabling notification sounds (default off)
  • Removed chat posts from search results and rss feeds (this change will also prevent people from receiving badges based on their chat activity)
  • Fix for user being unable to log in on latest stable
  • More assertive CSS to make it harder to steamroll Babble from within theme components
  • Moved the audio tag, which I believe has fixed the OAuth login trouble (@Genyus could you help me confirm this? I can login via Facebook on the sandbox just fine at the moment.)
  • Add fix for long words not wrapping correctly sometimes
  • Pushed a locale update (yay German and Dutch!)

Let me know what other requests you have?


Great work! I noticed that every chat that gets sent in Babble shows up in the latest topics on the sidebar plugin.

I’m the maintainer of the sidebar blocks plugin, and, sad to say, but this is less of a Babble issue and more of a “Discourse Sidebar Blocks” plugin issue. (Unless this is something that changed recently, but I doubt it…)

1 Like

Sorry for the delay, James. Tried to test this yesterday but was blocked a coincidental bug in Discourse itself:

With that issue fixed, I’ve re-tested but am still seeing the same behaviour.

It seems like there’s something wrong with your setup, for example visiting results in a 404, whereas sends the notification audio file. Any reason you can think of that this might be the case? What other plugins, or customized code on the server side, might be interfering?

Apologies, when I was testing before, I disabled the plugin to see if it still behaved the same way as previously — whereby it tries to load the .mp3 URL, but as the plugin is disabled, it renders the 404 page instead of downloading the file. I’ve re-enabled it now.

Hm, so the bug exists when Babble is present, but disabled, and someone logs in with OAuth?

I’ve just pushed a fix so that the notification file is not loaded unless a) Babble is enabled b) there are chats for the current user to participate in c) the sound option is enabled for that user, which I’m hoping will clear up most of the use cases here. We still have to check though that users who are loading the mp3 are able to sign in with OAuth. :confused:

1 Like

Correct. If the plugin is enabled, then the browser downloads the .mp3 file on login. If it’s disabled, it still attempts to open that URL, but it fails and renders the 404 page instead.

Incredible, James. Just freakin’ incredible! You’ve put so much into Babble in these last couple of weeks and it’s getting better and better. :fireworks:

For those of you who didn’t follow the previous Babble mega thread, the fact that James is pouring so much into Babble is all the more admirable when you read his context here.

Alright. Now for test results, James. I just did a round of testing with Babble 4.0.3 and there are some things that don’t work the way that I expect. I thought I’d send you a PM with the details, but others may be experiencing the same things, so I thought I’d put them here instead.

Sound Notifications Aren’t Working in a Specific Scenario

Let’s start with how I believe this should work:

I know you developed this feature specifically for my community (thanks!). It’s just not working the way I expect so far.

Here’s the scenario:

I tested this across browsers, mobile/tablet/desktop, and with Babble toggled open and closed. The result was always the same.

The good news is that 1:1 DMs within Babble and @ mentioning someone does generate the notification sound.

Side note: If you have multiple Discourse tabs open, the sound cascades across the tabs every 3-10 seconds. It’ll play in one tab, then another tab a few seconds later, then another tab a few seconds later, and so on.

User Level Babble Options Not Available When a User Isn’t a Moderator or Admin

A user doesn’t see the new Babble options at unless they have either Moderator or Admin privileges as defined at Without Moderator or Admin set to Yes, they don’t see the “Disable Babble chat completely” or “Enable browser sound for new chat notifications” at all.


Perhaps this is by design. If it were me, I’d give access to the user level Babble options regardless of admin or moderator status and regardless of trust level. I don’t see the point of restricting the options.

Closing Babble on Mobile and Left Behind Animation Grayness

This could be due to the more assertive CSS changes you made so I can’t steamroll Babble as much or due to our unique Puttytribe community CSS.

  1. Scroll down on a page
  2. Toggle Babble open
  3. Select a chat room
  4. Toggle Babble closed

Following those steps, it leaves a gray horizontal line leftover from where the closing animation failed to seemingly finish.


Thanks for the excellent bug reporting; I’ve pushed some fixes for these.

  • Sound notifications should be much more reliable now, and trigger when you a) have a chat open and receive a message, or b) are directly messaged or mentioned somewhere. I’m thinking about splitting these into two separate user preferences, since if it were me I might be interested in the setting where I’m told someone’s trying to talk to me, but not every time someone decided to post an emoji in the random channel I have open.

  • I’ve fixed the user level babble options so they appear for everyone

  • I’ve also patched up the adaptive height setting, which I believe was causing your issue. I think it’s a much less erratic setting now, and now calculates the height of the chat on resize / scroll based on the difference between the bottom of the header element (.d-header), and the bottom of the screen

1 Like

So sorry, James. I don’t know how I managed to reply to the first half of your message and somehow glaze over the second half where you mentioned that you’d pushed an update for this :man_facepalming:t5:

I just tested with and without notifications enabled and experienced no issues; all OAuth options now work as expected. :tada: Thanks so much for your diligence on this and apologies again for the delayed feedback.

That sounds wonderful to me.

Agreed. It’s fixed.

Whatever was causing my issue is now gone with your recent updates.

I have a little more testing to do about the sound notifications since they aren’t triggering on mobile or tablet view, even when I allow notifications at the browser level in Firefox or Chrome. I need to more thoroughly test before I can make a report on that.

I’m trying to create a chat channel based on a group and I get this error

Hm, ive pushed a fix for that particular error, although I dont think it was particularly related to creating a group channel. Can you let me know if that fixes it for you?

That fixed it, thank you! Amazing plugin btw.

1 Like

I gave up and had to disable it and then later after a discourse update the plugin caused my instance to fail to launch so I removed it.

I may check again later but the risk is not worth the feature.