Community help? Known non-functioning shadow dom elements/events?

[BMCwebdev]

Hoping I can poll the community here.

So we know that there are some aspects of RAC that will not work in a shadow tree. One of them is the onPress prop. However you can use onPressEnd which is closer to onClick.

If anyone has any experience with other known issues when using RAC in a shadow tree it would be very helpful. We have built our design system component library on RAC, and have a team that are prototyping a project using a shadow dom. It would be really helpful if we went into it knowing more about what we might run up against.

Thank you everyone.

[devongovett]

One of them is the onPress prop. However you can use onPressEnd which is closer to onClick.

Both of these are fired during the native onClick so they should be the same? Curious what difference you're seeing there. We do have tests for press events in shadow roots:

react-spectrum/packages/@react-aria/interactions/test/usePress.test.js

Line 3911 in 8573562

describe('usePress with Shadow DOM', function () {

There are certainly other issues. It's not officially supported everywhere, but there have been some contributions to improve it in various areas. It's sort of in a "try it and see if it works" state.

[snowystinger]

Would be good to capture and consolidate in #7687 as well

[BMCwebdev]

I can test again, but what I was finding was when using a Button component, the onPress event produced no effect. I did not dig deep, so I could find out more, such as did the event even begin, was it a bubbling issue, etc. Ill update.

Thanks for the response, and all the work you both do. I'm very happy I chose React Aria Components for our design system!

[BMCwebdev]

Okay, been a while, finally had time to work on this. The short version is that, for me, onPress does not work inside of a shadow dom:

Shadow DOM Issue: Root Cause (?) - Event Target Retargeting Breaking onPress

Summary

I've conducted an investigation into the Shadow DOM issues with React Aria Components and think I have identified the root cause. The onPress event fails in Shadow DOM due to event target retargeting that breaks React Aria's press gesture validation logic.

This follows up on the discussion in #8378 where I mentioned onPress doesn't work but onPressEnd does. I think I can now explain why this happens.

The Root Cause: Event Target Retargeting

When events cross the Shadow DOM boundary, event.target gets retargeted from the actual element to the shadow host. This breaks React Aria's internal press gesture validation.

My Sluething

I created event tracing that shows the problem:

Shadow DOM (BROKEN):

DOCUMENT-pointerdown: target="DIV" (shadow host)
DOCUMENT-pointerup:   target="DIV" (shadow host)
Result: onPress NEVER FIRES ❌
onPressStart: ✅ Works  
onPressEnd: ✅ Works

Regular DOM (WORKING):

DOCUMENT-pointerdown: target="BUTTON" (actual element)
DOCUMENT-pointerup:   target="BUTTON" (actual element)
Result: onPress FIRES ✅

Why onPressEnd Works But onPress Doesn't?

Looking at React Aria's global listeners, I can see the validation logic:

"if ((0, $d4ee10de306f2510$export$4282f70798064fe0)(state.target, (0, $d4ee1..."

This function appears to validate that the pointerup target matches or is contained within the original pointerdown target. In Shadow DOM:

1. pointerdown: React Aria records shadow host DIV as the target
2. pointerup: Also receives shadow host DIV due to retargeting
3. Validation Failure: React Aria expects the actual BUTTON element, not the retargeted host
4. Result: Press gesture recognition fails, onPress never fires

onPressEnd works because it doesn't require the same target validation - it fires on any pointerup event.

Why it's an issue for my component library

This is particularly problematic for my component library built on React Aria because:

1. Internal patterns break: DialogTrigger, MenuTrigger, etc. rely on onPress working internally
2. Can't be worked around: Consumer code can't fix internal React Aria event handling
3. Accessibility concerns: These patterns are core to accessible interactions

Example that fails in Shadow DOM:

<DialogTrigger>
  <Button>Open Dialog</Button> {/* No explicit onPress - handled internally */}
  <Modal>...</Modal>
</DialogTrigger>

Technical Details

• React Aria Version: Latest (using React Aria Components)
• Browser: Tested in Chrome, Safari, Firefox
• Shadow DOM Mode: open
• Event Types Affected: pointerdown, pointerup, and derived press events

The issue is consistent across all modern browsers and appears to be fundamental to how Shadow DOM handles event retargeting rather than a browser-specific bug.

That's all I got for now. Hope this was helpful.

[snowystinger]

Thanks for the details!

Just checking, are you using the feature flag for shadow dom? have you called

react-spectrum/packages/@react-stately/flags/src/index.ts

Line 24 in 06dca5b

export function enableShadowDOM(): void {

in your application?

Do you have a codesandbox or stackblitz where you were doing this research? it'd be great to have an easy place to go to reproduce

[BMCwebdev]

Oooo! Didn’t know about this flag, will try in the morning.

Been working locally with either a dev server or storybook, can move to a code sandbox or whatnot.

I’ll get back to you tomorrow. Thanks @snowystinger

[BMCwebdev]

Fantastic! Enabling this fixed the issue for me. The combination of both UNSAFE_PortalProvider and enableShadowDOM have really helped me as I needed to find a solution and had to work within the structure of the app.

I cannot thank you enough, this has helped immensely !

For the heck of it, below, I will attach the solution I was going to try to use, but so happy to use your solution instead.

Would it still be helpful to share my test cases?

Thanks again @snowystinger

[BMCwebdev]

Shadow DOM Solution for React Aria Components (edit: no longer going to use in favor of React Aria's enableShadowDOM)

The Problem

React Aria Components' onPress event fails in Shadow DOM due to event target retargeting. When pointer events cross the Shadow DOM boundary, the browser retargets event.target from the actual element (e.g., BUTTON) to the shadow host (e.g., DIV). This breaks React Aria's press gesture validation logic.

The Solution

Intercept pointer events at the document level before React Aria sees them, and fix the retargeted events using a Proxy that returns the correct target.

Implementation

/**
 * Install Shadow DOM fix for React Aria Components
 * This must be called BEFORE React Aria adds its event listeners
 */
function installShadowDomFix() {
  // Store the original addEventListener
  const originalAddEventListener = EventTarget.prototype.addEventListener;
  
  // Override addEventListener to intercept pointer events
  EventTarget.prototype.addEventListener = function(type, listener, options) {
    // Only intercept pointer events at document level
    if (this === document && ['pointerdown', 'pointerup', 'pointercancel'].includes(type)) {
      
      // Wrap the listener to fix event targets
      const wrappedListener = function(event) {
        // Get the real target from composedPath
        const composedPath = event.composedPath();
        const actualTarget = composedPath[0];
        const eventTarget = event.target;
        
        // Check if we have Shadow DOM retargeting
        if (actualTarget !== eventTarget) {
          // Create a proxy event with fixed target
          const proxyEvent = new Proxy(event, {
            get(target, prop) {
              if (prop === 'target') {
                return actualTarget; // Return the real element, not shadow host
              }
              // For all other properties, return original value
              const value = target[prop];
              if (typeof value === 'function') {
                return value.bind(target);
              }
              return value;
            }
          });
          
          // Call the original listener with our fixed event
          return listener.call(this, proxyEvent);
        }
        
        // No Shadow DOM involved, proceed normally
        return listener.call(this, event);
      };
      
      // Register the wrapped listener
      return originalAddEventListener.call(this, type, wrappedListener, options);
    }
    
    // For all other events, proceed normally
    return originalAddEventListener.call(this, type, listener, options);
  };
}

How It Works

1. Monkey-patches addEventListener: Overrides the native method before React Aria uses it
2. Targets specific events: Only intercepts pointerdown, pointerup, and pointercancel at document level
3. Detects retargeting: Compares event.target with event.composedPath()[0]
4. Creates proxy: Returns a proxied event where event.target returns the actual element
5. React Aria receives correct target: Sees BUTTON instead of DIV, validation passes, onPress fires

Usage in Stitch

Option 1: Auto-Detection

// In your app initialization
function initializeStitch() {
  // Check if we're in or might encounter Shadow DOM
  const root = document.getRootNode();
  if (root !== document || root instanceof ShadowRoot) {
    installShadowDomFix();
  }
}

Option 2: Manual Installation

// For applications that know they'll use Shadow DOM
import { installShadowDomFix } from '@stitch/shadow-dom-fix';

// Call before rendering any React Aria components
installShadowDomFix();

Option 3: React Provider

import { useEffect } from 'react';

export function StitchProvider({ children }) {
  useEffect(() => {
    // Install fix on mount
    installShadowDomFix();
  }, []);
  
  return children;
}

// Usage
<StitchProvider>
  <App />
</StitchProvider>

Important Notes

Timing

• MUST be installed before React Aria adds its event listeners
• Best placed at the very start of your application
• Cannot be removed once installed (would require page reload)

Scope

• Only affects the document where it's installed
• If running in an iframe, install in the iframe's document
• Does not affect events that don't cross Shadow DOM boundaries

Compatibility

• Works with all React Aria Components
• Fixes DialogTrigger, MenuTrigger, and other internal patterns
• No modifications to React Aria code required
• Transparent to component consumers

Performance

• Minimal overhead - only affects pointer events at document level
• Proxy is only created when Shadow DOM retargeting is detected
• Regular DOM events pass through unchanged

Validation

This solution has been tested and confirmed to work with:

• ✅ Button with onPress
• ✅ DialogTrigger (internal press handling)
• ✅ MenuTrigger (internal press handling)
• ✅ All onPressStart, onPress, and onPressEnd events

Limitations

1. Cannot be uninstalled: Once applied, requires page reload to remove
2. Global modification: Affects all event listeners on the document
3. Timing sensitive: Must be installed before React Aria initializes

Alternative Approaches Considered

1. Using onPressEnd instead of onPress: Insufficient - doesn't fix internal React Aria patterns
2. Custom event dispatching: Doesn't solve the root cause
3. Native onClick: Loses React Aria's accessibility features
4. Modifying React Aria: Would require forking and maintaining

Conclusion

This solution provides a production-ready fix for React Aria Components in Shadow DOM contexts. It's surgical, efficient, and requires no changes to existing component code. While not perfect, it enables full React Aria functionality in Shadow DOM environments until official support is added.

[snowystinger]

Would it still be helpful to share my test cases?

Always 😍

[BMCwebdev]

You got it. It's a conversion from my local storybook. So hopefully everything is working, I did not test it all out on stackblitz.

https://stackblitz.com/edit/vitejs-vite-q5hesyr2?file=src%2Fcomponents%2FShadowDomWithFlag.tsx

Thanks again!

[BMCwebdev]

Follow up note for those attempting the same madness as me. I also needed to use UNSAFE_PortalProvider to get all my portals inside the shadow dom. Then I also needed data-react-aria-top-layer (#8661) so that the inert on the host html or body (I forget where it gets applied) didn't wrap my shadow dom tree. Without data-react-aria-top-layer on my shadow dom tree, clicking anywhere would just resolve to the host <html> tag.

This is not in the above stackblitz. I can add later hopefully.

[BMCwebdev]

Hey @snowystinger I have an update in the form of a document I saved for myself for future possible implementation.

Currently when I render a Modal inside of the shadow dom, when I click on the overlay the modal does not close. For now I don't need it to, but the use case may come up. I have a work around for now, but thought I would share. Sorry, no test case for this one.

---

Shadow DOM Modal Dismiss Workaround

Problem

When using React Aria components inside a Shadow DOM, clicking on the modal overlay does not dismiss the modal, even though:

• isDismissable is set to true
• enableShadowDOM() from React Aria is called
• The overlay click events are being captured

Root Cause

React Aria's dismiss detection mechanism doesn't work properly within Shadow DOM boundaries. Even with enableShadowDOM() enabled, the library's internal event handlers for detecting "outside clicks" fail to trigger when the overlay is clicked.

The click reaches the overlay container, but React Aria's dismiss handler (which listens at the document level) doesn't properly handle events that originate from within a Shadow DOM?

Workaround Solution

1. Add click handler in myapp.js

In the connectedCallback method, after creating the overlay container:

// Workaround for Shadow DOM dismiss detection
// React Aria's dismiss detection doesn't work properly in Shadow DOM even with enableShadowDOM()
// We manually detect clicks on the overlay backdrop and trigger dismiss
this._overlayClickHandler = (event) => {
  // Check if the click target is the React Aria overlay backdrop (has data-rac attribute or something more robust)
  // and is a direct child of the overlay container
  if (event.target.hasAttribute('data-rac') && event.target.parentElement === overlayContainer) {
    console.log('[Shadow DOM Dismiss] Detected backdrop click, triggering dismiss');
    // Dispatch a custom event that the React components can listen for
    const dismissEvent = new CustomEvent('shadowDomOverlayDismiss', {
      bubbles: true,
      composed: true,
      detail: { reason: 'backdrop-click' }
    });
    this.shadowRoot.dispatchEvent(dismissEvent);
  }
};
overlayContainer.addEventListener('click', this._overlayClickHandler);

2. Clean up in disconnectedCallback:

// Remove overlay click handler
try {
  if (this._overlayContainer && this._overlayClickHandler) {
    this._overlayContainer.removeEventListener('click', this._overlayClickHandler);
    this._overlayClickHandler = null;
  }
} catch {}

3. Listen for the event in MainApp.js

Add this effect in the AppContent component:

// Listen for shadow DOM overlay dismiss events
useEffect(() => {
  const handleShadowDomDismiss = (event) => {
    console.log('[MainApp] Received shadowDomOverlayDismiss event:', event.detail);
    if (isAppOpen) {
      toggleApp(); // Close the app when overlay is clicked
    }
  };

  // Listen on the shadow root if available
  const shadowRoot = portalContainer?.getRootNode?.();
  if (shadowRoot && shadowRoot !== document) {
    shadowRoot.addEventListener('shadowDomOverlayDismiss', handleShadowDomDismiss);
    return () => {
      shadowRoot.removeEventListener('shadowDomOverlayDismiss', handleShadowDomDismiss);
    };
  }
}, [isAppOpen, toggleApp, portalContainer]);

How It Works

1. The overlay click handler detects clicks on the React Aria overlay backdrop (identified by the data-rac attribute)
2. It dispatches a custom event shadowDomOverlayDismiss through the shadow root
3. The React component listens for this event and triggers the modal dismissal

Identified Elements

• The React Aria overlay backdrop can be identified by:
  • Having the data-rac="" attribute or something more robust
  • Being a direct child of the overlay container (#overlay-root)
  • Having styling that indicates it's a full-screen overlay

[snowystinger]

Thanks, possibly related to #7751 ?

[BMCwebdev]

I'll take a look, thanks. I just also added in a Popover, and same. It won't close when I click outside of it. I can close it with esc key and by clicking on the trigger button again. I can also interact with other React Aria components in the shadow dom (like inputs etc) while the popover is open. Just some quick info.

Thank you again. I'll look more into that issue you linked.

[snowystinger]

You don't have to look into it. I was just making sure I (and our team) didn't lose track of possibly related things.
If you want to, we definitely appreciate it, but by no means am I requiring you or asking you to look into it. You've been extremely helpful already.