Widgets Customizer should work without animations and transitions enabled

[kevin940726]

Description

Possibly related failing tests: https://github.com/WordPress/gutenberg/runs/2620274056

Currently, the Widgets Customzier only works with "Disable the CSS animations" plugin disabled. It's because the customizer API rely on transitionend to work. We might want to find a new way to workaround that until we fixes it in core.

Step-by-step reproduction instructions

1. Enable "Disable the CSS animations" test plugin (It's easier to enable it via wp-env in the test environment)
2. Go to Appearance -> Customize -> Widgets

Expected behaviour

The editor should load.

Actual behaviour

The editor doesn't load.

Screenshots or screen recording (optional)

WordPress information

• WordPress version: trunk
• Gutenberg version: trunk
• Are all plugins except Gutenberg deactivated? Disable the CSS animations plugin should be activated
• Are you using a default theme (e.g. Twenty Twenty-One)? Yes

Device information

• Device: Desktop
• Operating system: macOS 11.3.1
• Browser: Brave 1.23.71 (Chromium 90)

[adamziel]

The bug is caused by the following rule: transition-duration: 0s !important, presumably due to some race condition with transitionend event involved. If I change it to transition-duration: 0.01s !important then everything suddenly works. I am going to try to identify the problematic part of the JS code.

[adamziel]

This subscriber isn't getting called with transition-duration: 0s:

https://github.com/WordPress/gutenberg/blob/8667e9688867004755dce39225f185baf9558f3d/packages/customize-widgets/src/components/customize-widgets/index.js#L30-35

I don't know the customizer code very well so I'll leave it at that. We could go drill down all the way to the root cause or just go for the 0.01s workaround. The latter should be fine considering this is just a test plugin, what do you think?

[kevin940726]

This is actually a bug in core, so I'm not sure why I didn't post it there 😅.

Yes, we can solve it by patching the test plugin, but I'm afraid that the plugin exists for a reason? I wonder if it's an accessibility issue if we don't support it. Maybe some browsers or extensions will automatically register similar override as well? @tellthemachines might have some insights that I'm not aware of 🙇‍♂️.

As for the root cause is along these lines:

https://github.com/WordPress/wordpress-develop/blob/bdf7dd6299e4453f9d7438de0a0e138d950ec0bf/src/js/_enqueues/wp/customize/controls.js#L1294-L1305

The completeCallback, which the Widgets customizer depends on, never fires if there's no transitionend event. However, we could probably fix it here though if that's easier.

[tellthemachines]

I wonder if it's an accessibility issue if we don't support it.

We should definitely support animations being turned off! Some users have them disabled at a system level for a11y reasons.

I'm not sure why we're using that plugin for the e2e tests though. Might be a matter of speed? Not having to wait for animations to finish?

[getsource]

I did a bit of looking into this.

I’m not sure it’s ideal, but this looks to fix the problem referenced in the description:

diff --git wp-admin/js/customize-controls.js wp-admin/js/customize-controls.js
index c8ee3de8..e5d07929 100644
--- wp-admin/js/customize-controls.js
+++ wp-admin/js/customize-controls.js
@@ -906,7 +906,7 @@
 			'WebkitTransition': 'webkitTransitionEnd'
 		};
 		prop = _.find( _.keys( transitions ), function( prop ) {
-			return ! _.isUndefined( el.style[ prop ] );
+			return ! _.isUndefined( el.style[ prop ] ) && ! _.isEmpty( el.style[ prop ] );
 		} );
 		if ( prop ) {
 			return transitions[ prop ];

Some background:

I believe the plugin folks are talking about is this one, from the Gutenberg end to end tests. As mentioned by others, it disables animations by setting the times/delay to 0ms.

This does, in fact, currently break the Widgets Editor in the Customizer:

Disable.Motion.Plugin.Enabled.mov

After the applying the diff above, it looks like this:

Disable.Motion.Plugin.Enabled.After.Fix.mov

As far as I can tell, the plugin’s behavior is different from the behavior of turning on “Reduce Motion” in OSs/Browsers through the prefers-reduced-motion CSS media feature, which has some documentation here.

While prefers-reduced-motion is supported in some areas of WordPress, it does not appear to be honored with this part of the Customizer.

When I enable Reduce Motion in OSX, and test in Firefox, I see the same animation.
Reduce Motion disabled:

No.Reduce.Motion.mov

Reduce Motion enabled:

Reduce.Motion.mov

A little good news, as far as the problem described in the ticket, is that this means that the Widgets Editor in the Customizer looks to load with Reduce Motion in the OS enabled.

The animation still happening, even with Reduce Motion, looks like a separate bug needs to be fixed, though. I did a bit of looking and didn’t find an existing issue, so thinking it would be a good idea to open a separate ticket in trac for it.

Hopefully this helps!

[getsource]

I made a Core trac ticket for Reduce Motion for the Customizer sliding transitions mentioned, here:
https://core.trac.wordpress.org/ticket/53542

[adamziel]

@getsource great job getting to the bottom of that!

I’m not sure it’s ideal, but this looks to fix the problem referenced in the description:

Would you please create a new diff with that fix so that we can mark this issue as closed? :-)

[getsource]

Sure! I'll get a core trac ticket created with a patch.

I'll link to it here as soon as it's there. This might be tomorrow for me at this point, as I've had a few issues with my core dev environment during the process of creation + testing.

[getsource]

Ticket with patch created here:
https://core.trac.wordpress.org/ticket/53562

[kevin940726]

I opened a PR in core which should solve this issue: WordPress/wordpress-develop#1608.

Once it's merged, we only need to tidy up some code in the tests :).

[getsource]

Thank you, this looks great! I'll take a look, test, and leave a comment on the core tickets as well today.

[getsource]

Okay, thanks again everyone!
I just made a follow-up commit, here: https://core.trac.wordpress.org/changeset/51677

Please let me know if anything else is necessary here.

[noisysocks]

Closing this as I see that https://core.trac.wordpress.org/ticket/53542 is now closed.