Reopening: the race condition still exists in the code. This issue was closed because the functional tests work around it, not because it was fixed.
The mechanism, in the current code:
flamingo/docextra.vm registers, on dom:loaded, an extraInit function that calls XWiki.displayDocExtra() for the first tab (usually Comments).
XWiki.displayDocExtra() (in xwiki.js) loads a tab with an Ajax.Request whose onComplete unconditionally calls dhtmlSwitch(extraID). There is no request counter and no cancellation of an obsolete request.
So when a second tab is opened while that initial load is still in flight, the two responses race and the last one to arrive wins the active tab \u2014 exactly the scenario described in this issue. The counter-based fix suggested by Sergiu in the description was never implemented.
Note that ViewPage.openDocExtraPane() waiting for the target pane to become visible does not close the race: the wait returns as soon as (for instance) Historypane becomes visible, and a Comments response landing a few milliseconds later hides it again.
The window is small in practice (the initial request is issued at DOMContentLoaded while Selenium can only click after the load event has fired), which is why we do not see flickers any more. But the bug is still there, and some tests still carry explicit workarounds referencing this issue: VersionIT, CopyPageIT and PageTemplatesIT.
Fixing it properly in xwiki.js (ignore the response of a tab load that is no longer the last requested one) allows dropping those workarounds.
This message was sent by Atlassian Jira (v9.3.0#930000-sha1:287aeb6)
If image attachments aren't displayed, see this article.