Is the highlighting of the new rep on the profile page broken again or is it just me?

See also this related question I asked a while back: https://meta.stackexchange.com/questions/113926/highlight-reputation-in-profile


As the commenters below noticed. It does get highlighted (just for a second), but then it is gone.

  • I still see highlights. At which SE site do you observe this behaviour and in which browser?
    – Rob W
    Feb 11, 2012 at 21:29
  • 6
    I'm seeing it show up and disappear after less than a second (Safari 5.1.3, Mac OS X 10.7.3).
    – ughoavgfhw
    Feb 11, 2012 at 21:46
  • 2
    I'm getting the same as @ughoavgfhw - Chrome 16.0.912.77 m on Windows 7 Professional
    – ChrisF Mod
    Feb 11, 2012 at 23:53
  • @RobW SO and see comments above.
    – PeeHaa
    Feb 12, 2012 at 1:17
  • The same thing happens in the message tab. If you're in "post" mode for reputation you'll see the new ones in yellow as a separate block and then they'll get merged into the main list and un-highlighted once the page has finished loading. Feb 12, 2012 at 2:03
  • Same here - new rep shows highlighted and at the top momentarily, then rearranges to collapse into "normal" order and loses the highlights. Chrome 18 beta, occurring on Server Fault. Feb 12, 2012 at 9:18
  • We're making some big, internal changes to how rep is stored - this will be addressed soon. Feb 13, 2012 at 19:57
  • @JarrodDixon thanks for keeping us in the loop!
    – PeeHaa
    Feb 13, 2012 at 19:58
  • 1
    @JarrodDixon You guys know that this specifically is an issue with History.js on the profile page though, right?
    – Tim Stone
    Feb 14, 2012 at 4:07
  • I brought this up on the Science Fiction & Fantasy Meta. It's quite frustrating and seems to be confined to Chrome and Safari.
    – Tango
    Feb 15, 2012 at 3:57
  • This is not limited to the list of reputation changes, it also happens for the favorites list and the responses list, new/updated entries just lose their highlight color after a second or so. CC @JarrodDixon It doesn't seem related to reputation changes. Feb 17, 2012 at 7:43

2 Answers 2


There was an underlying behavior change here in which the data in the initial history state pushed by the plugin after another change was {} rather than null, meaning that this part of the event handler was no longer behaving correctly:

var s = History.getState();
if (!s || !s.data) return;

...that now needs an additional || !s.data.query on the end (we always push a querystring) to eliminate the case of the initial state pushed by the History.js plugin itself.

A fix has been pushed through all tiers and highlighting should stick around correctly now.

  • I assume this functionality was primarily intended to make the sorting options more smooth, but is there a reason the main profile tabs don't leverage this too? I couldn't see an obvious explanation, but maybe I overlooked something.
    – Tim Stone
    Feb 20, 2012 at 13:39
  • @TimStone - it wouldn't be a simple application, since the tabs themselves have changing numbers/content we'd have to change how things are loaded all around. Also, plugins are loaded at the per-tab level, for example reputation requires Highcharts. It's not that it'd be that much work for just the tabs, just not a net positive in some cases due to HTML5 and history/current/synchronicity corner cases. For example loading the reputation tab and it showing a different number than the summary above means another meta bug, the same for badge counts. Feb 20, 2012 at 13:52
  • Ahh, yes, that makes a lot of sense. I'm a bit ashamed I didn't consider that; thanks for the explanation!
    – Tim Stone
    Feb 20, 2012 at 14:13

Since it was suggested that I meddle, the problem stems from the fact that the History.js code that's being used on the user's page is firing a statechange event when the page loads, which causes the current tab to be immediately reloaded from the server via AJAX.

As there's some latency in the request, you see the original page for a brief period of time, after which it's replaced by the re-requested content. Given that the original request was recorded as you having viewed the new content, the re-requested view returns the tab as if you had already viewed it, effectively "unhighlighting" the new entries you were viewing.

One potential issue here is that #tabs a isn't bound to the event handler that would allow the tabs to be loaded asynchronously, so switching between tabs in the user profile requires an entire page reload. This may or may not be by design, but since the handler reloads the entire tab for the other cases anyway, it seems sensible that the whole profile would be handled this way as well.

The larger problem of course is that the History.js code is firing the statechange event on load and the code doesn't account for this. I've used that plugin in the past, and I remember this being the case. However, the most recent version of the bundled code seems to actually not fire that event when the page first loads because of some changes in isLastSavedState(). Swapping in the code used on Stack Exchange however did still result in the event being fired on load in the demo page.

I couldn't find the code that would compress to the version used currently in user.js, so I'm unsure how to account for the discrepancy, but either accounting for it in the code or updating the History.js code that seems to be included in user.js should most likely fix this issue outright. As a test, I swapped in the updated History.js code by intercepting the user.js request with Fiddler to return my modified copy, and doing so seemed to produce the expected (corrected) behaviour.

You must log in to answer this question.

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