Page MenuHomePhabricator

ULS tooltip loads before Vector's collapsible nav is applied
Closed, InvalidPublic

Description

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.


Version: unspecified
Severity: normal

Details

Reference
bz51170

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:44 AM
bzimport set Reference to bz51170.

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

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
Copy of screenshot from comment 0 (http://i.imgur.com/dYrtm2d.png) for posterity

Attached:

dYrtm2d.png (581×478 px, 47 KB)

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.