[Bug] Wrong `pointerEvents` behaviour on 0.21.1

[staszekscp]

Is there an existing issue for this?

• I have searched the existing issues

Describe the issue

While working on the bump we've noticed that pointerEvents behaviour has changed causing multiple strange bugs in the app. After an investigation I noticed that in many places the pointerEvents got overridden by other inherited values.

After creating a minimal reproduction I discovered that the pointerEvents worked correctly in the previous version. However they must have been passed to components via StyleSheet.create(). When passed by inline styling or a JavaScript object, box-none nor box-only properties were not applied.

The previous version worked correctly, because even when passing the pointer-event only to the closest children via > * CSS was taking care of everything via inheritance.

Screen.Recording.2025-08-22.at.11.47.10.mov

Expected behavior

Passing the pointerEvents property should behave the same no matter if passed by StyleSheet.create() or inline styling.

What's more I believe that the previous StyleSheet.create() implementation should be brought back, since it worked as I would expect:

<View style={styles.pointerEventsNone}> // none
  <View style={styles.pointerEventsBoxNone}> // none
  // From here we should have 'auto'
    <View> 
      <View 
        onClick={() => {
          console.log("Should work");
        }}
      />
    </View>
  </View>
</View>

The only thing would be to make sure the same logic as in StyleSheet/compiler/index was applied for any other way of styling.

Steps to reproduce

Inline styling bug

1. Add a View with inline style={{ pointerEvents: 'box-none'}}
2. Open Elements in the Inspector and notice that the style was not applied

Wrong propagation

1. Add a View with style={{ pointerEvents: 'none'}} (created via StyleSheet.create())
2. Nest another View with style={{ pointerEvents: 'box-none'}} (created via StyleSheet.create())
3. Nest one more View with an onPress
4. The onPress should be triggered, since its parent has box-none value, therefore its children should get pointerEvents: 'auto' following heuristic that descendants should inherit from the closest ancestor.

Test case

https://codesandbox.io/p/sandbox/condescending-wildflower-z6vzpv

Additional comments

• react-native-web v0.20.0 reproduction - The event get triggered only when passing pointerEvents via StyleSheet.create()
• react-native-web v0.21.1 reproduction - In both cases the buttons don't work while they should
• React example - shows a similar case where the button gets triggered, even though the grandparent has the none value

[necolas]

Thanks for providing the kind of debugging and write up that OSS projects dream about.

@hassankhan #2797 appears to be the cause of this regression.

I'll leave you both to determine the best way to fix this

[staszekscp]

In the implementation of StyleSheet.create() I see that the function returns the same object it has received as argument. In theory we could extract the logic related to style compilation and execute it for all styles passed to components:

function generateCSSClasses(styles) {
  Object.keys(styles).forEach(key => {
    var styleObj = styles[key];
    // Only compile at runtime if the style is not already compiled
    if (styleObj != null && styleObj.$$css !== true) {
      var compiledStyles;
      if (key.indexOf('$raw') > -1) {
        compiledStyles = compileAndInsertReset(styleObj, key.split('$raw')[0]);
      } else {
        if (process.env.NODE_ENV !== 'production') {
          validate(styleObj);
          styles[key] = Object.freeze(styleObj);
        }
        compiledStyles = compileAndInsertAtomic(styleObj);
      }
      staticStyleMap.set(styleObj, compiledStyles);
    }
  });
}

function create(styles) {
  generateCSSClasses(styles)
  return styles;
}

In the component

StyleSheet.generateCSSClasses(props.style)

What do you think about this approach? Any concerns?

[necolas]

The problem is that inline objects are recreated each render. Only the static styles are worth compiling and caching.

But pointerEvents had some special handling to map the prop to compiled styles. So that could probably be done for pointerEvents in inline styles too

[staszekscp]

Thanks for the answer, that gives much more context! In that case I think the simplest solution would be to include pointerEvents passed in the style prop in the handling you've linked.

Here's a draft PR with the change. It's a draft, since I was unable to test it properly yet, but from a small reproduction it seems like it should work just fine.

[staszekscp]

Hey @necolas! 👋🏻 I have had time to test the PR better and it seems it works just fine with my fix, so it's ready for review!