VisualEditor can get stuck when using Windows with reduced animations
Closed, ResolvedPublicBUG REPORT
Actions

Assigned To

Authored By

	Hyperwombat
	Jan 1 2025, 3:08 PM

Description

Steps to replicate the issue (include links if applicable):

Set Settings/Ease of Access/Simplify and personalize Windows/Show animations in Windows -> Off
Edit a MediaWiki page using VisualEditor
Save the changes
Try to edit the same page again without reloading the page

What happens?: VisualEditor gets stuck loading and doesn't become functional again until the page is reloaded.

What should have happened instead?: VisualEditor should load normally.

Software version (on Special:Version page; skip for WMF-hosted wikis like Wikipedia): MediaWiki 1.43.0+

Other information (browser name/version, screenshots, etc.): It started with MediaWiki 1.43 and is still happening with the current version used on mediawiki.org (VisualEditor:Test). I could reproduce it on multiple computers running Windows 10 with Firefox, Chrome and Edge. Couldn't test Windows 11.

Event Timeline

Hyperwombat created this task.Jan 1 2025, 3:08 PM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 1 2025, 3:08 PM

Maintenance_bot added a project: VisualEditor.Jan 1 2025, 3:29 PM

I can reproduce.

Probably caused by relying on the transitionend event here: https://gerrit.wikimedia.org/g/mediawiki/extensions/VisualEditor/+/0b50aef4252cc5dbfb2b36ae2c969d81322673a3/modules/ve-mw/init/targets/ve.init.mw.DesktopArticleTarget.js#945

(Aside: It's not clear to me whether this is really the correct behavior from the browsers… The docs at https://developer.mozilla.org/en-US/docs/Web/API/Element/transitionend_event list several cases where the event will not fire, but not the case where the user disabled animations. The spec at https://drafts.csswg.org/css-transitions/#accessibility-motion says something interesting: "User agent implementors should be aware that Web content may depend on the firing of transition events, so implementations of such mitigations may wish to fire transition events even if the transitions were not run as continuous animations. However, it is probably poor practice for Web content to depend on such events to function correctly.".)

It should probably be replaced with a hardcoded delay (unless reduced animations are active).

There are a few more uses of transitionend, but they're not too important. We actually have one place where it is mentioned that it "doesn't seem to work reliably", and a hardcoded delay is used instead: https://gerrit.wikimedia.org/g/mediawiki/extensions/VisualEditor/+/0b50aef4252cc5dbfb2b36ae2c969d81322673a3/modules/ve-mw/init/targets/ve.init.mw.MobileArticleTarget.js#219

malberts subscribed.Apr 6 2025, 11:52 AM

I can reproduce this on Linux (Fedora 41 KDE).

Steps: Disable system animations via System Settings > Animation speed > Instant.

Same behavior as in OP, tested with Firefox 137, Brave 1.77.95, Chromium 135.0.7049.52.

When system animations are disabled, the browser reports "prefers reduced motion" is enabled (example: https://webkit.org/blog-files/prefers-reduced-motion/prm.htm), and VisualEditor gets stuck.

When enabling system animations (any value except "Instant"), then "prefers reduced motion" is not enabled, and VisualEditor works as expected.

vitaly-zdanevich subscribed.Feb 12 2026, 2:32 PM

Confirming on Gentoo Linux, Firefox 147.0.4

Fixed by https://gerrit.wikimedia.org/r/c/VisualEditor/VisualEditor/+/1268697 + https://gerrit.wikimedia.org/r/c/mediawiki/extensions/VisualEditor/+/1268695

VisualEditor can get stuck when using Windows with reduced animationsClosed, ResolvedPublicBUG REPORTActions

Description

Event Timeline

VisualEditor can get stuck when using Windows with reduced animations
Closed, ResolvedPublicBUG REPORT
Actions