You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
SafeAreaView doesn't respect padding property in style #22211
renders nested content and automatically applies paddings
Seems like intended behaviour from the docs. Try adding padding to your view inside the SafeAreaView instead.
Reacted by Damir Minnegalimov, togglebytes, MJ Studio, KahTim, Aliyar Taravati, Nathan Daix, Tony Eneh, Matheus Richard, Ana Beatriz, Önder Bakırtaş and 17 more
Thanks for the response, @bartolkaruza. I was wondering if it would be better if the padding applied by the consumer was added to the safe area one, instead of being overwritten. Thinking about it, the way the SafeAreaView component achieves its behaviour is more an implementation detail.
If the padding is added to the already in place padding that the SafeAreaView adds automatically, the next opened issue will be from someone asking why the padding value is not exactly the number of pixels specified by the style. Maybe someone would expect to be able to override the padding by using the padding style for some cases, which wouldn't work... Are the complexity and additional discussion worth it when the solution is putting in a containing view on which you can apply all the styles you want?
Perhaps a note in the docs specifying more clearly that the padding style property is ignored would save the next person some time? Maybe a warning message could take it even a step further. Feel free to open a PR for that if you have the time.
Reacted by Nathan Pierce, Shrikant Kalar and saifullah rahman
I wanted to share my thoughts regarding this because I found the current approach not ideal. I discussed this internally before creating the issue and people agreed with me that this was confusing.
If someone uses SafeAreaView I expect them to know that it will define new bounds and that all style properties applied to it would work in base to those new bounds (otherwise they would have used a View in the first place). The fact that internally SafeAreaView uses padding to accomplish this it's just, IMO, an implementation detail that shouldn't concern the consumer.
I thought the additional discussion was worth it and that's why I brought it up.
Adding a containing view is what we're doing now and it feels unnecessary, given that SafeAreaView already takes a View's style property. I also thought about the warning message, there are components out there that filter out forbidden properties and warn about their usage in dev mode, this could rise awareness about this particularity, but it wouldn't solve the underlying issue.
To add another argument, in native iOS you can create a constraint relative to the safeAreaLayoutGuide without having to create a containing view to do it.
I would love to find time to help improving this somehow, I just wanted to know what people think about it first!
Reacted by Uche Nkadi, Henrik T., Seyed Mohammad Asadi and Stains M Johnson
@esr360 Until this issue is solved, you need to add another view inside the SafeAreaView and apply your padding there, because SafeAreaView uses the padding style prop to implement its behaviour, overriding the one you pass to it.
Reacted by Edmund, Shahzad, Saurabh Ranjan, Patric Gekoski and Sebastian Zelonka
Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may also label this issue as a "Discussion" or add it to the "Backlog" and I will leave it open. Thank you for your contributions.
Based on how popular silently ignoring and overriding a style attribute has been with the react-native core team & community for the last six years, I think it would be worth rolling out this feature to more components.
Many components could benefit from the functionality and expressiveness SafeAreaView gives developers who would like to be able to safely store integer values inside of style attributes without the unwanted side-effect of applying layout changes on some platforms.
It's been 4.5 years since we merged the PR that added the link to this issue to the official docs (react/react-native-website#1847).
I wanted to celebrate almost 5 years of getting notifications about this with my current solution to the problem: don't use SafeAreaView.
Unless you have a very simple app with basic routing (a hello world demo), you should go for flexibility and use useSafeAreaInsets from https://github.com/th3rdwave/react-native-safe-area-context (as mentioned by @a-eid and @magom001). It should help you avoid weird components wrapping when using tabs or drawers, background color issues and animation shenanigans.
Activity
bartolkaruza commentedon Nov 9, 2018
Seems like intended behaviour from the docs. Try adding padding to your view inside the
SafeAreaViewinstead.dani-mp commentedon Nov 9, 2018
Thanks for the response, @bartolkaruza. I was wondering if it would be better if the padding applied by the consumer was added to the safe area one, instead of being overwritten. Thinking about it, the way the SafeAreaView component achieves its behaviour is more an implementation detail.
bartolkaruza commentedon Nov 9, 2018
If the padding is added to the already in place padding that the SafeAreaView adds automatically, the next opened issue will be from someone asking why the padding value is not exactly the number of pixels specified by the style. Maybe someone would expect to be able to override the padding by using the padding style for some cases, which wouldn't work... Are the complexity and additional discussion worth it when the solution is putting in a containing view on which you can apply all the styles you want?
Perhaps a note in the docs specifying more clearly that the padding style property is ignored would save the next person some time? Maybe a warning message could take it even a step further. Feel free to open a PR for that if you have the time.
dani-mp commentedon Nov 9, 2018
I wanted to share my thoughts regarding this because I found the current approach not ideal. I discussed this internally before creating the issue and people agreed with me that this was confusing.
If someone uses SafeAreaView I expect them to know that it will define new bounds and that all style properties applied to it would work in base to those new bounds (otherwise they would have used a View in the first place). The fact that internally SafeAreaView uses padding to accomplish this it's just, IMO, an implementation detail that shouldn't concern the consumer.
I thought the additional discussion was worth it and that's why I brought it up.
Adding a containing view is what we're doing now and it feels unnecessary, given that SafeAreaView already takes a View's style property. I also thought about the warning message, there are components out there that filter out forbidden properties and warn about their usage in dev mode, this could rise awareness about this particularity, but it wouldn't solve the underlying issue.
To add another argument, in native iOS you can create a constraint relative to the
safeAreaLayoutGuidewithout having to create a containing view to do it.I would love to find time to help improving this somehow, I just wanted to know what people think about it first!
esr360 commentedon May 1, 2019
Sorry but I'm a bit confused about this issue.
I have applied padding to a
SafeAreaViewcomponent. In Android it is applied, in iOS it isn't. What is the reason, and what is the solution?Thanks.
dani-mp commentedon May 1, 2019
@esr360 Until this issue is solved, you need to add another view inside the SafeAreaView and apply your padding there, because SafeAreaView uses the padding style prop to implement its behaviour, overriding the one you pass to it.
stale commentedon Aug 4, 2019
Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may also label this issue as a "Discussion" or add it to the "Backlog" and I will leave it open. Thank you for your contributions.
41 remaining items
github-actions commentedon Jul 24, 2023
NorseGaud commentedon Nov 4, 2023
Just stumbled across this issue myself what a strange waste of my time trying to figure out what I was doing wrong, only to be surprised.
brunaporato commentedon Feb 8, 2024
sad to bump into this unfixed problem :(
Mahmoudz11 commentedon Feb 17, 2024
6 years until now
andshonia commentedon Apr 22, 2024
My approach maybe will help you:
DDunc commentedon May 16, 2024
Based on how popular silently ignoring and overriding a style attribute has been with the react-native core team & community for the last six years, I think it would be worth rolling out this feature to more components.
Many components could benefit from the functionality and expressiveness SafeAreaView gives developers who would like to be able to safely store integer values inside of style attributes without the unwanted side-effect of applying layout changes on some platforms.
shivang98 commentedon Aug 15, 2024
This works for me!
Add a View inside SafeAreaView and provide styling separately, as shown below.
Kipperlenny commentedon Oct 14, 2024
as a beginner with react native, I had the same problem.... Thank you @shivang98
aldebout commentedon Oct 15, 2024
It's been 4.5 years since we merged the PR that added the link to this issue to the official docs (react/react-native-website#1847).
I wanted to celebrate almost 5 years of getting notifications about this with my current solution to the problem: don't use SafeAreaView.
Unless you have a very simple app with basic routing (a hello world demo), you should go for flexibility and use
useSafeAreaInsetsfrom https://github.com/th3rdwave/react-native-safe-area-context (as mentioned by @a-eid and @magom001). It should help you avoid weird components wrapping when using tabs or drawers, background color issues and animation shenanigans.react-native-bot commentedon Apr 14, 2025
This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.
react-native-bot commentedon Apr 21, 2025
This issue was closed because it has been stalled for 7 days with no activity.
SamarthKadam commentedon May 8, 2025
Instead of using padding propertly use. paddingHorizontal and paddingVertical. it would work