https://bugzilla.wikimedia.org/show_bug.cgi?id=58106
--- Comment #3 from Bartosz Dziewoński <[email protected]> --- This is caused by two problems, one of which is somewhat easy to fix when you know what to look for (see below), and the other not so much. The second problem is, obviously, the fact that *there's just so much code*, and executing more code usually takes more time. I think even loading VE requires less. Seriously, this is mad. The first is that elements are sometimes first inserted into DOM, and then "filled" with their children. This causes continuous reflows and repaints when executing the script. The 81.82% "idle" time in Helder's log is spent on reflows, repains and other related browser activities. The worst offender here seems to be jquery.wikibase.entityview, which does `$( '<div/>' ).appendTo( this.element ).claimgrouplistview( { … } )` – where the .claimgrouplistview() call generates the entire list of claims that spans several screens of text. If you scroll down during the loading of the page, you can see the claims being built part-by-part in real time. The obvious fix – changing the order of operations – seems to cause all of the edit links not to appear (unless I borked something else). I did not investigate the root cause, probably something somewhere ten levels of abstraction deep calls .parent()/.closest(), which at that point returns an empty collection due to the element being parentless. Somebody more knowledgeable about the code will probably be able to track this down easily. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
