Nativescript: [TNS 3.0] iOS:Layout will not update on modal page

[kssfilo]

Which platform(s) does your issue occur on?

iOS

Please provide the following version numbers that your issue occurs with:

• CLI: 3.0.0
• Cross-platform modules: 3.0.0
• Runtime(s): 3.0.0
• Plugin(s): -

Please tell us how to recreate the issue in as much detail as possible.

1. create default project with iOS platform(tns create..)
2. make a modal page like below and open it by tap event on 1st page

<StackLayout>
 <Label id=‘label1’ text=‘short’ textWrap=‘true’ />
 <Button button=‘label’ text=‘tap’ />
 <Label id=‘label2’ text=‘’ textWrap=‘true’ />
</StackLayout>

1. in modal pages tap handler, modify label1 or label2 text property to long text(like ‘foooooooooooooooooooo……’)

-> text will be not wrapped(label1) and text will not be shown (label2)

Besides this issue, I found that another UI has similar problem in modal page. such as Html or Image. when expanding height of these UI parts programmatically, no layout change happens.

When text or src or html property is bound to model. The behavior is same.This problem is very critical when bounded properties initial value is null. (Nothing shown when setting value.)

I checked same test on non modal page and seems ok. so the problem looks like modal page specific issue.

[tsonevn]

Hi @kssfilo,
If I understand you correctly after you opened a Modal page, you update text value for the Labels with a long string and the new text is not rendered properly.
I tested this case on my side, however, it seems to work as expected. Please review the attached file and verify, whether I am missing something.
Archive.zip

[kssfilo]

You have to write updating text code into Tap handler not loaded(). like this.

export function loaded(args:EventData){
}

export function onTap(args:EventData){
    var page:Page =<Page> args.object.parent;
     var label:Label = <Label> page.getViewById("label1");
     label.text="fooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo

     var label2:Label = <Label> page.getViewById("label2");
     label2.text="foooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
}

Additionally,If xml's Label is "visibility='collapsed'" and change it to "visible" on Tap handler, nothing shown.

I found that similar problem happens not only textWrap/ height property or visibility property and StackLayout.

<GridLayout columns="auto,*"><Button id='button1' col='0' text='short' /></GridLayout>

in case Button ui is like above, if you change button1's text to 'veeeryLong" in Tap handler, button will be '.....'. It seems same issue of updating layout in Modal page.

[kssfilo]

Only workaround I found is calling this after changing properties. (but it's difficult when property is bound to model.)

page.nativeView.setNeedsLayout()

[tsonevn]

Hi @kssfilo,
Thank you for the above-given example.
I was able to reproduce this behavior while changing the text of the Labels on the Button tap instead of changing the value of the property on page loadedEvent.
I am attaching sample project, which could be used for debugging.
Archive.zip

[kssfilo]

OK. Thank you.

[kssfilo]

I found that cause of this problem is UI(Button/Text..)’s text property doesn’t have affectLayout option.

I tried to change “tis-core-modules/ui/text-base/text-base-common.js” like below, Everything is working fine.

exports.textProperty = new view_1.Property({ name: "text", defaultValue: "" })

->

exports.textProperty = new view_1.Property({ name: "text", defaultValue: "", affectsLayout: view_1.isIOS })

But I think this change causes performance issue.

I suggest that TextBase must have a way to annotate whether a text property needs affectsLayout or not by XML. (for example, adding special text property such as “expandableText” , or annotation property like ‘affectsLayout=“text src” )

Sorry, I checked again, workaround above is not effective.

only valid workaround currently is calling ""Page.nativeView.setNeedsLayout()" after changing property.

[piotrilski]

It seems to be affecting usage of *ngIf and *ngSwitch on angular as well. I made a fork of sdk-examples-ng repo here: https://github.com/piotrilski/nativescript-sdk-examples-ng/tree/pilski/modal-issue
Changes I made: https://github.com/piotrilski/nativescript-sdk-examples-ng/pull/1/files
To see what's going on simply run it and go to ModalPage -> Modal Page Example and hit first EnterStartDate button to open a slightly modified modal. It behaves exactly like in

[tsonevn]

Hi @kssfilo,
I am glad to hear that you have found a workaround for this issue.
Regarding that, you could create your pull request, which will provide a fix for this problem. If all test passed we will merge it to the modules repository. For further help, you could also review contribute article.

@piotrilski indeed there is an issue with using *ngIf and *ngSwitch directives in a Modal page, however, in my opinion, this is separated issue which is related only for NativeScript Angular 2. In this case, I opened a new issue in a NativeScript Angular repository, where you could keep track for some further info.

[kssfilo]

https://github.com/kssfilo/NativeScript/tree/fix-modal-layout

I made some change to tns-core-modules and send PR #4170 .

My apps and @tsonevn 's sample app are working like before 3.0.0 without "Page.nativeView.setNeedsLayout()" workaround now.

[toddanglin]

Ah! This sounds like the cause of one of the MAJOR headaches I'm having upgrading a 2.5 iOS app to 3.0.

Before 3.0, I was able to hide/show layouts in a modal view using model properties bound to the visibility property (think: loading/error/normal view states). After 3.0, layouts that are not visible on the initial load are never displayed, even when their bound visibility properties are true.

Gave this workaround a quick test and it works! This is definitely a regression in the layout system.

@tsonevn We should prioritize this bug/fix given that it is a breaking change regression in 3.0 from 2.5.x.

[SvetoslavTsenov]

Hi, the fix is merged in master and already available with tns-core-modules@next so any feedback will be highly appreciated.

[toddanglin]

Thanks! Will give it a try as soon as I can.

[dtopuzov]

Fix will be released in 3.0.1 later this week.

[toddanglin]

@dtopuzov Great! Will that version be 3.1.0? Or 3.0.2? I think 3.0.1 is already released. :)

[dtopuzov]

Fix will be in [email protected].
We already released hot-fix for CLI, so there is [email protected], but current version of tns-core-modules is still 3.0.0.

[toddanglin]

Got it! Thanks for clarifying.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.