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.
