If you click to star a post on the side (in the starred list), it changes color but not the star by the main chat area (it does add one to the number, but it doesn't change the color). Then when you click the star on the main chat area, it changes color to yellow but lowers the number by one

After clicking in sidebar:

After clicking in the main chat:

  • 7
    – animuson StaffMod
    Jul 9, 2012 at 20:45
  • I think it does change the color of the other star but only after refresh
    – Ben Brocka
    Jul 9, 2012 at 21:40
  • I can confirm this.
    – user176088
    May 3, 2013 at 17:54

2 Answers 2


From now on (assume you have fresh JavaScript, in other words you have loaded the chat page after the change was deployed), the various starring events will cause the correct stars to display on the chat message, no matter where that event originated.


There are actually two related issues here... or possibly just one basic design issue, depending on how you want to look at it.

The two immediate design issues are that:

  1. Clicking the star icon in the sidebar toggles the sidebar icon itself, but not the corresponding icon on the starred message.
  2. When the sidebar is refreshed using an Ajax request, the star icons are not propagated to the starred messages themselves.

I've written a client-side JS fix for the SOUP user script that fixes both of these issues. Here's the code for it:

var syncMsgStar = function () {
    var $this = $(this);
    var starred = $this.hasClass('user-star');
    var id = $this.closest('li').attr('id').match(/\d+/)[0];
    var msgStar = $('#message-' + id + ' .stars');

    if ( starred ) msgStar.addClass('user-star');
    else msgStar.removeClass('user-star');
var selector = '#starred-posts .sidebar-vote';
// XXX: this needs to run after the SE click handler; looks like it does
$(document).on( 'click', selector, syncMsgStar );
SOUP.hookAjax( /^\/chats\/stars\b/, function () { $(selector).each(syncMsgStar) } );

The syncMsgStar function, when called on a sidebar star icon element, locates the corresponding star icon on the message and adds or removes the user-star class (which is what controls the yellow star color) to make it match the sidebar. The bottom two lines ensure that this function is called both immediately after clicking the sidebar star icon, and also (for all starred messages in the sidebar) after the sidebar has been updated in response to chat events, thus ensuring that the star icon on the message remains in sync with the sidebar.*

I've added this fix to the development branch of SOUP, and it should be part of the next stable SOUP release (v1.40).

Oh, and that basic design issue? Well, the chat WebSocket protocol uses the same event type for starring and unstarring a message. The JSON data for (un)star events helpfully includes the new star count and the ID of the user who (un)starred the message, but not whether the message was starred or unstarred.

Thus, in order to reliably update the "starred by me" status of messages based solely on chat events, I'd have to rely on the former state of the star icons being correct — and I can't safely do that, since that's precisely what this bug is about. (If I assumed the current, broken behavior, my SOUP code would break if this bug was ever fixed by SE.)

Adding a simple boolean flag to (un)star chat events, or separating star and unstar events into two different event types, would make updating the star icons much simpler and more reliable. I suspect this would be true even for the SE chat code itself; it's certainly true for any third-party script like SOUP that tries to hook into it.

*) I suspect that there remains a rare corner case where, if you have the same chat room open in multiple browser windows / tabs at the same time, and in one tab you un-star a message which you've previously starred, and which someone else has also starred, and this causes the message to drop out of the sidebar while still remaining visible and starred in the main chat area, then the yellow star highlighting may not be properly removed from the message in the other tab(s). This case is hard enough to trigger that I haven't managed to properly test it; I'm also pretty sure that nobody will ever trigger it just by accident. Anyway, this is the one remaining case I could fix, if only the chat WebSocket messages would clearly distinguish star and unstar events.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .