Opening and closing slideout too fast causes elements on browser not accessible

[vnali]

Description
I noticed clicking on an asset field several times quickly makes HTML output below without 'so-visible' class. As a result, elements on that page are not accessible anymore.
<div class="slideout-shade" style="display: block;"></div>

Maybe this is not an issue that happens all the time, and it took me some time to reproduce that, so please close this issue if this is not a common scenario.

Additional info

• Craft version: 3.7.134
• Chrome and Firefox desktop

[brandonkelly]

I’m unable to reproduce this, but will keep it open and keep an eye out for it.

[rogertinch]

Still present in Craft 5.10.13.2, and it doesn’t require fast clicking. Here’s a deterministic reproduction and what I think is happening.

Repro (any CP page, DevTools console; no plugin or fast clicking involved):

const so = new Craft.Slideout(
  Object.assign(document.createElement('div'), {innerHTML: '<p>probe</p>'}),
  {containerElement: 'div'}
);
setTimeout(() => so.close(), 600);
// ~2s later, the page is unclickable; the first click anywhere is swallowed.
setTimeout(() => {
  const s = document.querySelector('.slideout-shade');
  console.log(getComputedStyle(s).display, getComputedStyle(s).pointerEvents, s.className);
  // -> "block" "auto" "slideout-shade"
}, 2000);

Closing a real slideout with Escape produces the same result.

What I measured

After the slideout closes, the shade remains display: block; opacity: 0; pointer-events: auto at z-index: 100, covering the full viewport. It’s invisible but still receives pointer events. document.elementFromPoint() over a sidebar nav link returns the shade, and a click on that link never reaches it.

The second click works because the first dismisses the shade, which I think is why the bug appears intermittent.

Clearing the inline style changes the shade’s computed display to none. .slideout-shade:not(.visible){display:none} already hides it. The inline display: block written by jQuery’s .show() in open() is the only thing keeping it on the page. The deferred .hide() call never runs.

The deferral happens in close():

this.$shade.removeClass('so-visible');
this._afterTransition(this.$shade, () => { this.$shade.hide(); });

_afterTransition() runs the callback immediately when Garnish.prefersReducedMotion() is true. Otherwise, it waits for transitionend.

With reduced motion off, I attached native listeners for transitionstart, transitionend, and transitioncancel to the shade and watched a full open-to-close cycle. None of the three events fired, even though the opacity changed from 1 to 0. The pending transitionend never arrives, so hide() is never called.

I can’t say why the transition event doesn’t fire. I only established that it doesn’t, which makes the callback unreachable.

That would also explain why this never reproduced for you: with reduced motion enabled, _afterTransition() takes the immediate path and hides the shade correctly.

Environment: Craft 5.10.13.2 (Solo), Chrome on macOS, prefers-reduced-motion: reduce set to false, and no so-visible class on the leftover element, matching the original report exactly.

The bare Craft.Slideout reproduction shows that the issue is in Craft’s slideout behavior and can affect every slideout in the CP.

[brandonkelly]

@rogertinch I’m not able to reproduce that. The console.log() call outputs:

none auto slideout-shade

Tested in Firefox 154.0b10 and Chrome 151.0.7922.138 on a Mac. What browser/OS are you using?

[rogertinch]

@brandonkelly Chrome 151.0.7922.138 on macOS 26.6.1.

[brandonkelly]

Can you try enabling safe mode and see if you can still reproduce?

[brandonkelly]

Craft 5.11.0 is out with a fix for this, via #19511.