User blog comment:Rupert Giles/Global Navigation January Update/@comment-24164361-20150218120017/@comment-452-20150218144136

As there was a "loading notifications" message in the previous iteration, I believe that the current behaviour is a bug.

The reason the bug is resolved by hovering (either over or out) is because the focus is being changed, and the script is checking (again) whether there are notifications available.

Without looking at the source, I assume that the reason it is not being automatically updated when they are loaded via a callback function is because the callback function is using the former DOM order, and someone forgot to update it with today's changes. (Off with their head.)

After looking at the source, I was (mostly) right, the update event is attached to the wrong element. (I don't have a copy of yesterday's DOM to compare.)

HTML Before:   [...] 	  Before, the very first element in the navigation menu was named #notifications

HTML After: ...  [...]     After, #notifications is a subelement, #notificationsEntryPoint is the top element.

Javascript, now: this.$notifications = $('#notifications'); this.$notificationsEntryPoint = $('#notificationsEntryPoint'); this.$notifications .mouseenter( this.proxy( this.updateCounts ) ) .mouseenter( this.proxy( this.fetchForCurrentWiki ) );

BZZZZZZTT, WRONG.

Once someone changes this.$notifications to this.$notificationsEntryPoint, and then tests it to make sure it works properly before it goes live it should work as it should.

This CSS will simulate the correct behaviour for now: .notifications-container.active #GlobalNavigationWallNotifications { display: block; } display: none; } .notifications-container.active #notifications { margin-top: 0; height:0; } height: 36px; width: 72px; display: block; margin-top: -36px; } What it does is expands the area of the #notifications element to cover the bell icon, simulating the mouseover event being in the correct place.
 * 1) GlobalNavigationWallNotifications.show {
 * 1) notifications {