This requires that *all* javascript with animation be modified to obey that option. ~~~~

beau wrote:

Some people with older PCs from pl.wiki report long times to expand or collapse changes on enhanced recent changes or watchlist too.

I was just pointed to "jQuery.fx.off = true;". It may be worth adding this option to the the Appearence tab of preferences.

(In reply to comment #3)

I was just pointed to "jQuery.fx.off = true;". It may be worth adding this
option to the the Appearence tab of preferences.

Cool! That works!

For those interested, there is now a small JavaScript snipped on [[mw:Snippets/Toggle_animations]] which adds a portlet link for toggling the animations, and saves the user preference in a cookie.

Interesting. Way better then setting fx.off in a per-user gadget; this way the setting is stored on the (slow/fast) computer itself. Though the Toolbox portlet is a way better place.

saibotrash wrote:

raised importance... that is annoying to wait 20 seconds after load for my watchlist to collapse all entries (yes, old computer - which should be enough!).

saibotrash wrote:

(In reply to comment #4)
The JS from [[mw:Snippets/Toggle_animations]] helps to switch off the animations - yes. But apparently they aren't causing the biggest part of the freeze after loading my (big) watchlist. 800 edits from the last 2 days (in Commons) to take 30 seconds to collapse (after the page is loaded)... This was way faster before the update. Is there already a bug about this?

Switching off the animations does indeed speed up the (un)watch notification after clicking the button.

Anyway: switching off the animations should be a setting or a gadget in MediaWiki itself and not via a JS snippet.

saibotrash wrote:

Btw: the code to insert in your common.js/monobook.js is:
$.fx.off = true;

• Bug 31832 has been marked as a duplicate of this bug. ***

Looking at other bugs that have been reported about this, at the problems that
this causes for people with slower computers, I think we *really* need to
provide a way for people to disable this.

The big question is: do we provide a user based (preference) or computer based (cookie) option?

saibotrash wrote:

(In reply to comment #11)

The big question is: do we provide a user based (preference) or computer based
(cookie) option?

User based preference: A: on for me, B: off for me, C: off on this computer (sets cookie).
;-)

saibotrash wrote:

but: as mentioned, $.fx.off = true; doesn't really help with slowness!

mr.heat wrote:

I vote for: Get rid of all this annoying, time consuming, tediously slow animations. Make the user interface react fast. If you really insist of animations, please, please make it very fast (0.2 seconds or less). When I click a link or button I don't want my computer to react like "I'm not sure what to do with your click, let me think about for a moment". This feels like working on a 1980s computer. When I click my computer knows what to do in a few nanoseconds. So do it! Don't waste my time.

I'm gonna suggest WONTFIX. I see no practical nor theoretical point in offering a user an option to enable or disable animations. These are things to be considered generally as part of the interface design.

The last thing I wanna see happen is situations where developers need to debug scripts with animations on and off. There are way too many "I want preferences" preferences already, this is not going to be one of them.

If animations are lagging, then the 'right' solution (in my opinion) is to not have animations in that case, the wrong solution would be to offer a way to manually disable them. users shouldn't have to care nor be aware of this.

If they're working smooth and fast and not annoying, then it's okay to have them in a sudle way where possible (like with the ajax watch/unwatch notification, those would imho be jumpy/annoying without an animation).

See bug 31832 for progress on fixing the lagging in the animation, making it animationless in environments where it would lag otherwise.

-accessibility: Doesn't seem related.

-bug 29876 (post-deployment): This is a new plugin, nobody is forced to use it, it's available for those that want to use the core script instead of their own. It can't be a regression since it didn't even exist before nor replacing something that existed before. If it's not stable enough for you, then wait until a future version before removing local plugins.

mr.heat wrote:

(In reply to comment #16)

-accessibility: Doesn't seem related.

If something is delayed 20 seconds for no good reason on older computers it surely is an accessibility issue.

I agree with the watch/unwatch animation. At this place (at the top of the page, moving the contents of the page down) an animation does make sense and it is very fast. 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.

(In reply to comment #17)

(In reply to comment #16)

-accessibility: Doesn't seem related.

If something is delayed 20 seconds for no good reason on older computers it
surely is an accessibility issue.

Accessibility refers to bugs that related to things that make using the site or features hard or impossible for blind and motor impaired users.

A time delay does not stop the functionality being used so it's not an accessibility bug.

(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

I don't know that this is serious enough to warrant the usability hit of adding yet another preference checkbox.

saibotrash wrote:

Unbelievable.... This is broken since the 1.18 deployment and no-one seems to want to fix it. At least a hack is known for switching off the useless animations - what is the hack to replace the ultra slow collapsing which freezes my whole browser for 30 seconds when I open my watchlist? Hey, it did collapse with 1.17 too - why is there a need to break working stuff?

Not everyone has an up to date pc with lots of processing power to waste. Btw: did you thought about developing countries? I guess the average PC there is not as fast as in the first world.

(In reply to comment #20)

I don't know that this is serious enough to warrant the usability hit of adding
yet another preference checkbox.

What solution would you suggest?

@Saibo, the slowness of the watchlist is not caused by the animation. And since I have never seen a collapsed watchlist, you must have some gadget or script enabled that makes it collapse, and the slowness is caused by that script.

(In reply to comment #22)

(In reply to comment #20)

I don't know that this is serious enough to warrant the usability hit of adding
yet another preference checkbox.

What solution would you suggest?

That we do nothing. With purpose and vigor.

I've yet to be convinced that this is actually a MediaWiki problem; reading this thread it seems like Saibo may be running gadgets or other javascript hooks.

(In reply to comment #23)

I have never seen a collapsed watchlist, you must have some gadget or script
enabled that makes it collapse, and the slowness is caused by that script.

It is a feature which comes with MediaWiki, and it should be working for everyone. For its documentation, see:

• [[meta:Help:Enhanced recent changes]]
• [[meta:Help:Watchlist#Expanded_Watchlist]]

(In reply to comment #25)

(In reply to comment #23)

I have never seen a collapsed watchlist, you must have some gadget or script
enabled that makes it collapse, and the slowness is caused by that script.

It is a feature which comes with MediaWiki, and it should be working for
everyone. For its documentation, see:

• [[meta:Help:Enhanced recent changes]]
• [[meta:Help:Watchlist#Expanded_Watchlist]]

Well, then, it appears the bug is with this specific feature and we should focus on fixing that.

(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

Afaik collapsibility of tabs is not the subject of this bug. The collapsible-tabs feature is independantly inside the Vector-extension and hasn't changed since a lot since 1.16. This bug was opened due to the slowness for some users with elements made collapsible by the jquery.makeCollapsible plugin.

This plugin is new in 1.18 and is not used anywhere by default (except for enhanced watchlist, which is a preference option off by default). It is not used in articles by default. Wikis are however encouraged to use jquery.makeCollapsible instead of other local plugins for better localization and browser compatibility (that was the intention for the inclusion of the plugin in the first place), however if there are blocking bugs in the plugin, wikis are free to not use 'mw-collapsible' and stick with the legacy 'collapsible' that should still work.

(In reply to comment #27)

Afaik collapsibility of tabs is not the subject of this bug.

The bug summary + comment #0 and comment #1 don't talk about any specific animation. I think tabs are included.

But thanks for pointing out that the tab collapsing has been there since 1.16.

saibotrash wrote:

(In reply to comment #25)

(In reply to comment #23)

I have never seen a collapsed watchlist, you must have some gadget or script
enabled that makes it collapse, and the slowness is caused by that script.

It is a feature which comes with MediaWiki, and it should be working for
everyone. For its documentation, see:

• [[meta:Help:Enhanced recent changes]]
• [[meta:Help:Watchlist#Expanded_Watchlist]]

Yes, it is this watchlist. Cannot imagine a watchlist without... Well, if it is a separate thing then we should open up a bug (if there is not one already).

Anyway - done (to get things forward here): [[:bugzilla:31945]] now.

Note -- as a general rule, animations are nice when they work.

Fade-out animations on roll-up hide/shows such as on enhanced watchlist and hidable tables are not an appropriate animation to have in the first place, and this particular animation should not be used in that particular area. Those should be removed, independently of whether or not they are slow or people like them. (An appropriate animation here would be a roll-up or roll-down.)

Where useful and desirable animations that remain are slow on slower machines, we should see about making sure those fall back to much more graceful behavior.

I don't think there's a general need for a "no animations" switch, as long as the behavior is sane to begin with (though a JS switch for the hardcore doesn't hurt).

(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)

Actually, I know plenty of people who already find the single animation annoying.

swalling wrote:

(In reply to comment #14)

I vote for: Get rid of all this annoying, time consuming, tediously slow
animations. Make the user interface react fast. If you really insist of
animations, please, please make it very fast (0.2 seconds or less). When I
click a link or button I don't want my computer to react like "I'm not sure
what to do with your click, let me think about for a moment". This feels like
working on a 1980s computer. When I click my computer knows what to do in a few
nanoseconds. So do it! Don't waste my time.

This.

People need to accept that the interface is going to require JavaScript. This is a fact of modern, interactive websites. What people should not accept is a slow, buggy interactive interface. The solution to bad interface animations is not no interactivity. It's fast, responsive interactivity used in a sparing way.

In the context above, I think this bug should be closed as WONTFIX.

mr.heat wrote:

I'm not sure why you quoted my post. I never talked about disabling JavaScript. You are wrong in so many ways. "Animation" is not "interactivity". It's the opposite. During an animation I can not do anything. All it does is wasting my time.

(In reply to comment #30)

Note -- as a general rule, animations are nice when they work.

Fade-out animations on roll-up hide/shows such as on enhanced watchlist and
hidable tables are not an appropriate animation to have in the first
place,
and this particular animation should not be used in that particular area.
Those
should be removed, independently of whether or not they are slow or people
like
them. (An appropriate animation here would be a roll-up or roll-down.)

Changing the summary per Brion. Do we have a list of inappropriate animations to be killed? Should it be a separate bug?

Where useful and desirable animations that remain are slow on slower
machines,
we should see about making sure those fall back to much more graceful
behavior.

I don't think there's a general need for a "no animations" switch, as long as
the behavior is sane to begin with

I suppose this bug can be closed (and the original request for another preference considered rejected/addressed) when the behaviour is sane, then.

I'm going to WONTFIX this per the comments above.

Please report any cases of particularly slow JavaScript as separate
bugs (for example bug 34876 or bug 59172) and they will be looked at.

If you are really very bothered by the JavaScript animations, add
$.fx.off = true; to your common.js subpage as suggested above.
(This will not have any effect on the few CSS-based animations used in
some places in MediaWiki and extensions; however, these are generally
less resource-intensive and can be gotten rid of by using an older
browser ;).)