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
Update
As the commenters below noticed. It does get highlighted (just for a second), but then it is gone.
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.
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.
