Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix stylesheet validation of functions with additional prototype methods #27264

Closed

Conversation

fmnxl
Copy link

@fmnxl fmnxl commented Nov 19, 2019

Summary

Some babel plugins add additional methods to Function.prototype (see https://github.com/MatAtBread/fast-async):

Function.prototype.$asyncbind = function $asyncbind(self, catcher) {
...

Although undocumented, React Native allows functions to be passed to StyleSheet.create() for dynamic styling:

const styles = StyleSheet.create({
  animalItem: height => ({ height })
});

If there are additional custom methods on Function.prototype, React Native's StyleSheetValidation.validateStyle will loop through these properties and raise an error because those properties are not valid style keys, because it loops through all properties, including inherited ones.

Simulator Screen Shot - iPhone 11 Pro Max - 2019-11-19 at 12 04 49

This PR modifies StyleSheetValidation.validateStyle to only loop through the style's own properties, instead of including inherited ones.

Changelog

[General] [Fixed] - Fix stylesheet validation for functions with custom prototype methods.

Test Plan

  • Tested that non-function style properties are still validated

@facebook-github-bot facebook-github-bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Nov 19, 2019
@pull-bot
Copy link

Messages
📖 📋 Missing Test Plan - Can you add a Test Plan? To do so, add a "## Test Plan" section to your PR description. A Test Plan lets us know how these changes were tested.

Generated by 🚫 dangerJS against 383a706

@fmnxl fmnxl changed the title Fix stylesheet validation of functions with additional prototype Fix stylesheet validation of functions with additional prototype methods Nov 19, 2019
Copy link
Contributor

@facebook-github-bot facebook-github-bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hramos has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

@react-native-bot
Copy link
Collaborator

This pull request was successfully merged by Freeman Latif in f464dad.

When will my fix make it into a release? | Upcoming Releases

@react-native-bot react-native-bot added the Merged This PR has been merged. label Dec 18, 2019
@fmnxl fmnxl deleted the fix-stylesheet-validation-for-functions branch February 6, 2020 17:29
NickGerleman added a commit to NickGerleman/react-native that referenced this pull request Jun 18, 2020
… Styles

facebook#27264 change stylesheet validation to avoid enumerating properties on the prototype of a style. It introduces a secondary behavior change, where null/undefined styles used to be tolerated but now lead to an exception. This is because `for in undefined` will noop where `for of Object.keys(undefined)` will throw.

This scenario of undefined/null styles seems to actually show up in practice and was previously well tolerated. E.g. `Button.js` has code that looks like this:

```jsx
const styles = StyleSheet.create({
  button: Platform.select({
    ios: {},
    android: {
      elevation: 4,
      // Material design blue from https://material.google.com/style/color.html#color-color-palette
      backgroundColor: '#2196F3',
      borderRadius: 2,
    },
  }),
```

For non ios/Android platforms, that creates a style object which looks like:
```js
{
  button: undefined,
  ...
}
```

This previously meant that the component would be unstyled if created, but now means out-of-tree platforms throw at require-time for Button.

This change restores the previous `for in` loop but adds a `hasOwnProperty` check to avoid properties on prototypes. Validated that importing Buttons will no longer cause an exception, and that invalid properties are still caught.
facebook-github-bot pushed a commit that referenced this pull request Jun 25, 2020
… Styles (#29171)

Summary:
#27264 changed stylesheet validation to avoid enumerating properties on the prototype of a style. It introduces a secondary behavior change, where null/undefined styles used to be tolerated but now lead to an exception. This is because `for in undefined` will noop where `for of Object.keys(undefined)` will throw.

This scenario of undefined/null styles seems to actually show up in practice and was previously well tolerated. E.g. `Button.js` has code that looks like this:

```jsx
const styles = StyleSheet.create({
  button: Platform.select({
    ios: {},
    android: {
      elevation: 4,
      // Material design blue from https://material.google.com/style/color.html#color-color-palette
      backgroundColor: '#2196F3',
      borderRadius: 2,
    },
  }),
```

For non ios/Android platforms, that creates a style object which looks like:
```js
{
  button: undefined,
  ...
}
```

This previously meant that the component would be unstyled if created, but now means out-of-tree platforms throw if the builtin Button component is required.

This change restores the previous `for in` loop but adds a `hasOwnProperty` check to avoid properties on prototypes.

## Changelog

[General] [Fixed] - Restore Previous Behavior for StyleSheet Validation of Null/Undefined Styles
Pull Request resolved: #29171

Test Plan: Validated that importing Buttons will no longer cause an exception, and that invalid properties are still caught.

Reviewed By: JoshuaGross

Differential Revision: D22118379

Pulled By: TheSavior

fbshipit-source-id: 650c64b934ccd12a3dc1b75e95debc359925ad73
grabbou pushed a commit that referenced this pull request Jul 22, 2020
… Styles (#29171)

Summary:
#27264 changed stylesheet validation to avoid enumerating properties on the prototype of a style. It introduces a secondary behavior change, where null/undefined styles used to be tolerated but now lead to an exception. This is because `for in undefined` will noop where `for of Object.keys(undefined)` will throw.

This scenario of undefined/null styles seems to actually show up in practice and was previously well tolerated. E.g. `Button.js` has code that looks like this:

```jsx
const styles = StyleSheet.create({
  button: Platform.select({
    ios: {},
    android: {
      elevation: 4,
      // Material design blue from https://material.google.com/style/color.html#color-color-palette
      backgroundColor: '#2196F3',
      borderRadius: 2,
    },
  }),
```

For non ios/Android platforms, that creates a style object which looks like:
```js
{
  button: undefined,
  ...
}
```

This previously meant that the component would be unstyled if created, but now means out-of-tree platforms throw if the builtin Button component is required.

This change restores the previous `for in` loop but adds a `hasOwnProperty` check to avoid properties on prototypes.

## Changelog

[General] [Fixed] - Restore Previous Behavior for StyleSheet Validation of Null/Undefined Styles
Pull Request resolved: #29171

Test Plan: Validated that importing Buttons will no longer cause an exception, and that invalid properties are still caught.

Reviewed By: JoshuaGross

Differential Revision: D22118379

Pulled By: TheSavior

fbshipit-source-id: 650c64b934ccd12a3dc1b75e95debc359925ad73
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API: StyleSheet Bug CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. Merged This PR has been merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants