Modal: iOS statusbar should not change back to default white background w/ black text upon opening

Right now, if you have a custom background-color ActionBar, opening a modal should not reset the statusbar color or should set it to the same as it was or could allow it to be custom set when the modal opens?

Anyone know what's up with this? The top image is when a modal is open.
The bottom image is just the main app view. Notice the statusbar matches the actionbar in bottom normal view. But when modal is open, it resets the status bar? Seems odd.

I've tried setting fullscreen to true as well as false on the modal when it opens which has no affect on the statusbar resetting.

@NathanWalker

@NathanWalker try setting "backgroundSpanUnderStatusBar" to true on the modally displayed page - solved this issue for me (in vanilla nativescript)

Ref: https://github.com/NativeScript/NativeScript/blob/master/tns-core-modules/ui/page/page.d.ts#L94-L97

I have the same issue, any update on that?

I had the same issue. Setting "backgroundSpanUnderStatusBar" to true in the ngOnInit method and it worked well. It would be nice if this was a default option, perhaps set in the ModalDialogParams class.

Could you tell me please, where to put this Setting "backgroundSpanUnderStatusBar" to true
for the page from where Modal is called or on Modal itself ?
Thanks

@sis0k0

Looks like this has returned as a problem in {N} 4.x without a remedy at moment.

Here’s a simple example repo which demonstrates the issue:

https://github.com/NathanWalker/modal-issues

Here is a playground setup similarly which shows different behavior:

https://play.nativescript.org/?template=play-ng&id=dj3x53&v=5

Observations:
Playground is not a viable way to test many issues since playground behavior is different than that observed in real app.

/cc @sis0k0 @EmilStoychev

@NathanWalker

@NathanWalker here is an example how you can achieve the desired functionality with latest version of tns-core-modules & nativescript-angular: https://github.com/manoldonev/ng-modal-test (this will work with nativescript-angular@6.0.0 when released as well).

Basically showModal(...) in HomeComponent opens a placeholder ng component HomeModalViewComponent that only contains page-router-outlet and in its ngOnInit(...) we are navigating to the actual modal content (HomeModalViewContentComponent).

Modal view status bar then can be customized in the HomeModalViewContentComponent via css:

.action-bar, .page {
    background-color: chocolate;
}

, or via html:

<ActionBar title="MODAL VIEW" backgroundColor="chocolate">
</ActionBar>

<StackLayout backgroundColor="chocolate">
    <Button text="CLOSE MODAL" (tap)="onTap()"></Button>
</StackLayout>

, or in code (if you have not defined ActionBar in html):

export class HomeModalViewContentComponent implements OnInit {
    constructor(private _params: ModalDialogParams, private _page: Page) { }

    ngOnInit(): void {
        // if you do not have ActionBar, you can change the status bar background like this
        // this._page.backgroundColor = "chocolate";
    }

    // ...
}

@manoldonev

Thank you for this example @manoldonev
Is there anyway to handle without setting up the modal as a child of some route?
Oftentimes modals need to open from anywhere, even lazy loaded modules. For example, a login modal which could prompt from anywhere and setting up as a child to many different potential routes could be tedious.

@NathanWalker

@NathanWalker currently not.

Generally for scenarios with shared modal dialogs (and no navigation within the modal) it would be best to bypass the approach with placeholder component that contains \<page-router-outlet> and directly open the modal content component with showModal(...). However, there is an open issue at the moment related to NativeScript/NativeScript#5746 -- basically in iOS11 the status bar is outside the "safe area" and as NativeScript apps render mostly within the "safe area" at the moment, we are unable to customize the status bar appearance as per your original requirement.

We are actively working on a different solution for NativeScript/NativeScript#5746 right now.

@manoldonev

Thanks @manoldonev - I was able to refactor couple projects to use page-router-outlet and placeholder modal component and must say, I kinda like it :) . Provides more flexibility since you can now have detail navigation in a modal so quite nice. I was able to circumvent the route handling by defining a reusable route structure for the modals we use which other route configs (lazy loaded or not) can simply utilize to add the extra sub route handling. 👍

It solves the white top bar :) I'll leave this open until #5746 is handled for now as that would likely provide ultimate flexibility to handle this way and the other way described.

@manoldonev

Ok so @manoldonev I take the above back I was able to circumvent the route handling by defining a reusable route structure... ;) Using references/variables inside route definitions with AoT production build does not work unfortunately. This is the issue:
angular/angular-cli#6784

So although in dev builds there are ways to make it more manageable, those solutions don't work when going to production with AoT build. In the end it would be nice to come up with a solution together which circumvents the need to define children explicitly for every single possible route a modal could appear.

@NathanWalker

@NathanWalker the master branch of https://github.com/manoldonev/ng-modal-test/ now demonstrates a possible solution that does not need to define children routes explicitly in order to open modal dialog from different locations (basically attaches the modal to the root viewContainerRef to achieve that). Note that currently this only works with nativescript-angular@next.

Navigation Menu

Repository navigation

Modal: iOS statusbar should not change back to default white background w/ black text upon opening #340

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Modal: iOS statusbar should not change back to default white background w/ black text upon opening #340

Description

Activity

NathanWalker commented on Aug 21, 2016

mnahkies commented on Sep 22, 2016

wiperez commented on Dec 14, 2017

morecchia commented on Dec 14, 2017

valeraf commented on Mar 26, 2018

NathanWalker commented on May 21, 2018

manoldonev commented on May 22, 2018

NathanWalker commented on May 22, 2018

manoldonev commented on May 23, 2018

NathanWalker commented on May 23, 2018

NathanWalker commented on May 24, 2018

manoldonev commented on Jun 12, 2018

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions