Last modified: 2014-05-04 05:06:42 UTC
ULS tooltip loads before Vector'scollapsible nav is applied. http://i.imgur.com/dYrtm2d.png The tooltip is shown where the cog was before the navigation got collapsed.
There is 500 ms delay for the positioning of the cog icon to let collapsible nav to do it's thing first. Looks like the tooltip is not using the same delay for positioning.
Change 111438 had a related patch set uploaded by KartikMistry: Set tooltip load timeout later than cog https://gerrit.wikimedia.org/r/111438
Change 111438 merged by jenkins-bot: Set tooltip load timeout later than collapsible navs https://gerrit.wikimedia.org/r/111438
Patch is merged.
It is, of course, a horrible workaround for an awful problem (the delay was increased from hardcoded 500ms to hardcoded 700ms, great…), and will not solve the issue in all cases, as Nike already commented on the patch. The author of the original code, whoever that person is, should feel bad for having written it.
Created attachment 14505 [details] Copy of screenshot from comment 0 (http://i.imgur.com/dYrtm2d.png) for posterity
Does anybody know what makes collapsible navs so effing slow or run so late on beta.wmflabs? Can it even send an event when it is ready? Or is someone going to remove it in a week?
Likely because there's an effing lot of extensions installed, many of which load and execute their own resources. Core could send an event / fire a hook after collapsing the sidebar, if only someone implemented it. It might be easier to fix this by doing less absolute positioning in ULS instead (which would mean that the tooltip will be in the correct position automagically).
(In reply to comment #8) > Likely because there's an effing lot of extensions installed, many of which > load and execute their own resources. Note that I was experiencing this bug on my own testwiki with almost no extensions as well; this largely depends on your computer's speed (how much time it takes it to render the page and execute other scripts, against the hardcoded 500/700 ms limit).
Better move this side of the conversation to the bug on its slowness, IMHO.
(In reply to Nemo from comment #10) > Better move this side of the conversation to the bug on its slowness, IMHO. Now fixed.
