https://bugzilla.wikimedia.org/show_bug.cgi?id=30401
--- Comment #31 from Krinkle <[email protected]> 2012-08-29 14:50:18 UTC --- (In reply to comment #19) > (In reply to comment #16) > > -bug 29876 (post-deployment): This is a new plugin, nobody is forced to use > > it, > > Seems to contradict: > > (In reply to comment #17) > > The "mw-collapsible" animations added in 1.18 do not make sense > > because nobody knows where the collapsible elements are placed, how big they > > are, for what they are used and so on. And to make it worse, the animation > > is > > way to slow. > > Plus, I don't remember enabling anything but I still get an animated > collapsing > of tabs in Vector at at times. I'm on a pretty fast computer, so it doesn't > bother me, but if I can imagine how such things would be a problem on slow > computers. May be time to set up a 486 for testing. :P The Vector tabs have been there since 1.17 since the very first version. Also those animations would never slow down the page because they are one single animation. The problems referred to in this page are mostly about jquery.makeCollapsible (which the Vector skin itself doesn't use, because there's built-in jQuery methods for what Vector does), and all are about multi-animation sequences. e.g. when jquery.makeCollapsible initializes on a page with many collapsible tables it slows down exponentially. That is bug in jquery.makeCollapsible because during initialization it shouldn't animate, only when a user clicks a button, and when a user does it is always for 1 single animation, which is marginal and hasn't had any complaints. So the solution is to fix jquery.makeCollapsible because eventhough it may not 20 seconds on a modern computer, it still freezes the browser for like 1 or 2 seconds which is unacceptable. That bug is tracked under bug 34876 and a fix is already on its way. If there are other modules that suffer from this bug (so far only makeCollapsible was mentioned), please file new bugs for those. They can be fixed very simple in the same way: by fixing the script to not request an untracked number of animations unconditionally at the same time. Because though that is most visible on a slow computer, it is never acceptable and thus should be fixed for everyone. Animations when triggered on user action and when appropiate for the scenario are fine and (at least so far) have never been a source of actual complaints. So, taking all into account. I agree with Trevor and Brion, resolving as "wontfix" is the way to go for this request (user option to disable jQuery animations generally) -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- 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
