What is meta? ×
Meta Stack Exchange is where users like you discuss bugs, features, and support issues that affect the software powering all 122 Stack Exchange communities.

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: http://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.

share|improve this question
    
I still see highlights. At which SE site do you observe this behaviour and in which browser? –  Rob W Feb 11 '12 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 '12 at 21:46
2  
I'm getting the same as @ughoavgfhw - Chrome 16.0.912.77 m on Windows 7 Professional –  ChrisF Feb 11 '12 at 23:53
    
@RobW SO and see comments above. –  PeeHaa Feb 12 '12 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. –  mu is too short Feb 12 '12 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. –  Shane Madden Feb 12 '12 at 9:18
    
We're making some big, internal changes to how rep is stored - this will be addressed soon. –  Jarrod Dixon Feb 13 '12 at 19:57
    
@JarrodDixon thanks for keeping us in the loop! –  PeeHaa Feb 13 '12 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 '12 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 '12 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. –  Daniel Beck Feb 17 '12 at 7:43
add comment

2 Answers

up vote 4 down vote accepted

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.

share|improve this answer
    
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 '12 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. –  Nick Craver Feb 20 '12 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 '12 at 14:13
add comment

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.

share|improve this answer
add comment

You must log in to answer this question.

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