Environment
Describe the bug
A picture is worth a thousand words:
So we start the app with one background color. Clicking the button swaps between the two other colors. So Pink initial, Green and Purple swapping.

The issue is that when you navigate away from a TabView, Tabs, Frame or BottomNavigation and then return, CSS is no longer changing the backgroundColor.
This exact same code pattern is in all four of them; I'll explain the issue using BottomNavigation code... It is a bit weird; but stepping through the code you can see why this is happen and understand what is occurring:
The code here (bottom-navigation):
https://github.com/NativeScript/NativeScript/blob/c150b11bf1818db39e8baef2ca3e792e89720ad2/nativescript-core/ui/bottom-navigation/bottom-navigation.android.ts#L100-L107
Saves the backgroundColor during the onDestroy. So that this code here:
https://github.com/NativeScript/NativeScript/blob/c150b11bf1818db39e8baef2ca3e792e89720ad2/nativescript-core/ui/bottom-navigation/bottom-navigation.android.ts#L383-L388
Can reset the original color. HOWEVER, this creates the side effect of messing up the ability for CSS to change the backgroundColor after this point. The reason why is in properties.ts on line 889:
const cssPropertyDescriptor = descriptor(cssValue, 2, false, false, false); // Notice the "2"
const stylePropertyDescriptor = descriptor(styleValue, 3, true, true, true); // Notice the "3"
A cssValue = 2 & a StyleValue = 3 so when you set a value via CSS you run the routine with a propertySource of 2. When you set the value via direct setter (i.e. style) you get the PropertySource of 3.
That code does checks/assignment is here:
https://github.com/NativeScript/NativeScript/blob/c150b11bf1818db39e8baef2ca3e792e89720ad2/nativescript-core/ui/core/properties/properties.ts#L844-L847
Because the control is being recreated; it runs the:
this.backgroundColor = this._originalBackground;
Which is setting the color back correctly, but ALSO sets the computedSource to 3..
So, now, when it goes to apply the CSS; the CSS is always PropertySource = 2. So, any changes in the css:background-color will now fail to apply since the _originalBackground promoted the computedSource to 3.
To Reproduce
Basically; have a page with a background-navigation, and create a css file with BottomNavigation { background-color: blue;} this page has a button in it that navigates to another page. This next page can use my NS-Theme loader, or it can manually create a new CSS element that is BottomNavigation { background-color: red;} and load the addition CSS (which changes the backgroundColor)
Expected behavior
CSS should still apply to backgroundColor after a .back() rebuilds the page...
Additional context
I'm actually unsure why the _originalBackground is being saved and re-applied --- since all CSS is actually re-applied during the onload (even before this value is reset) which does actually reset the BackgroundColor correctly. The only thing I can do is presume that maybe a bug where someone reported the BackgroundColor was set via a direct style set in code during the original load; and was lost because of navigation away and then return.
However, if this is the case -- all other properties that are set that way also will be lost during navigation away and then return when this control is destroyed... So if that is the case; maybe we need a method to save & re-apply all direct style properties on rebuilding during a back event?
Maybe the simplest solution is trying to comment out the resetting code in onLoad and see what happens with the tests; do they still pass. If so, kill all that extra code with a vengeance. :D
If they don't pass then maybe we change the resetting to be control.style["css:backgroundColor"] = _originalBackground this should keep the computedProperty = 2.
Hello together,
I am seeing a similar issue which might be related to the bug here, therefore I did not add an extra issue for now. The bug only appears on Android. I use a tabs element, from the tabs element I than do a forward navigation. When I navigate back, the transparent background is lost and I see the default white background instead. I also use css to set the background to transparent. See pictures below:
Tabs Screen:

Forward navigation to details screen:

after router.goBack to tabs view:

What do you think? Same issue or should I consider to add an extra issue?
Best regards,
Christoph
"nativescript": {
"tns-android": {
"version": "6.5.1"
},
"tns-ios": {
"version": "6.5.1"
}
},
"nativescript-angular": "^8.21.0",
@cjohn001 - This is the same issue. I totally forgot about this issue -- at the point I logged it I had no control over the repo, so I logged the issue so It would be logged. I'll assign myself, and we will see if we can get this fixed soon.
We see nearly the exact same issue with a slight catch in nativescript-angular.
We also have a Tabs component but for the background we use a GridLayout across the full screen, as we are using an SVGImage for a background (which is not supported via css).
But this is also removed from the screen.
Is there any temporary workaround for this? So we can re-apply the GridLayout with the SVGImage inside after navigatin back to the screen?
@NathanaelA you know my PR https://github.com/NativeScript/NativeScript/pull/8791 should fix that :D
Now that fragment are not destroyed on forward navigation you should not need that hack anymore, right?
@Firetrip,
NathanaelA mentioned a workaround here.
https://github.com/NativeScript/NativeScript/pull/8510#issuecomment-677986073
I was unfortunately not able yet to get it working. If you know how to do it, it would be great you could post a code snippet here.
yeah so what we have for the default use case of css background being removed:
const backgroundElement: any = isAndroid ? this.page.getViewById('background-element') : this.page;
backgroundElement.backgroundImage = '~/images/non-overwritable-png/backgrounds/chat-background.png';
backgroundElement.style.backgroundSize = 'cover';
backgroundElement.style.backgroundRepeat = 'repeat';
note: the background-element is the TabsComponent
That code is called everytime onLoaded
But I cannot wrap my head around how to apply this fix to our full-page background GridLayout.
Most helpful comment
@NathanaelA you know my PR https://github.com/NativeScript/NativeScript/pull/8791 should fix that :D
Now that fragment are not destroyed on forward navigation you should not need that hack anymore, right?