search

NativeScript / nativescript-angular

Integrating NativeScript with Angular
http://docs.nativescript.org/angular/tutorial/ng-chapter-0
Apache License 2.0
1.21k stars 241 forks source link

Broken layout in iOS after upgrading to Nativescript 5 #1599

Closed marklanhamhc closed 5 years ago

marklanhamhc commented 5 years ago

Environment Provide version numbers for the following components (information can be retrieved by running tns info in your project folder or by inspecting the package.json of the project):

This is what I get when I run tns doctor:

✔ Your ANDROID_HOME environment variable is set and points to correct directory. ✔ Your adb from the Android SDK is correctly installed. ✔ The Android SDK is installed. ✔ A compatible Android SDK for compilation is found. ✔ Javac is installed and is configured properly. ✔ The Java Development Kit (JDK) is installed and is configured properly. ✔ Xcode is installed and is configured properly. ✔ xcodeproj is installed and is configured properly. ✔ CocoaPods are installed. ✔ CocoaPods update is not required. ✔ CocoaPods are configured properly. ✔ Your current CocoaPods version is newer than 1.0.0. ✔ Python installed and configured correctly. ✔ The Python 'six' package is found. ✔ Xcode version 10.1.0 satisfies minimum required version 9. ✔ Getting NativeScript components versions information... ✔ Component nativescript has 5.0.0 version and is up to date. ✔ Component tns-core-modules has 5.0.2 version and is up to date. ✔ Component tns-android has 5.0.0 version and is up to date. ✔ Component tns-ios has 5.0.0 version and is up to date.

Describe the bug Layout is broken in iOS. Android works fine. iOS was working fine before upgrading from NS4 to NS5.

To Reproduce See sample project in Playground example below.

Expected behavior Home page shopping lists should be stacked without overlapping.

Sample project See example here: https://play.nativescript.org/?template=play-ng&id=eGOyrq&v=13

cerealexx commented 5 years ago

Same here... any workarounds?...

marklanhamhc commented 5 years ago

Nope, no workarounds that I know of. I was told to try and downgrade tns-core-modules as this seems to be where the issue is (I believe tns-core-modules handles layout) but it just created more issues.

cerealexx commented 5 years ago

I've tried multiple combinations of GridLayout, FlexboxLayout and StackLayout and everything gets overlapped in iOS. This is really frustrating since we need to update our app and wont be able to publish until this gets fixed... Android on the other hand works fine.

thequiet commented 5 years ago

Same issue here.

Update: Reverting my "tns-core-modules" did seem to solve the problem for me.

marklanhamhc commented 5 years ago

Same issue here.

Update: Reverting my "tns-core-modules" did seem to solve the problem for me.

Just out of interest, what tns-core-modules version did you roll back to? And did you find that HMR still worked?

NickIliev commented 5 years ago

@thequiet @cerealexx hey guys in NativeScript 5.0.0 the iOS Safe Area support was introduced and it can be controlled via a boolean property called iosOverflowSafeArea. Detailed information can be found in this documentation section. Meanwhile, if your layouts are looking bigger or out of place please do check the linked article and try introducing iosOverflowSafeArea property set to false for those layouts.

If anyone has a specific case and needs further assistance please do create a Playground demo and I will be happy to investigate it.

@marklanhamhc you case seems not to be relaated to the Safe area support but more to the template option used with the structural directive ngFor inside the scrollview. We are still ireviwing this one but please do let us know if you have more insights on the issue.

NickIliev commented 5 years ago

@marklanhamhc it seems that using the Angular's 'ngFor' structural directive along with the NativeScript's StackLayout is causing this one in cases where the items does not have predefined size (e.g. Stacklayout with no width) and you are creating a dynamicly resized ScrollView which waits for the right sizes. We are currently investigating why the making and paddings are not applied as expected.

Meanwhile, as a workaround, you could create the same logic while directly using the Label component instead of StackLayout.

<ScrollView scrollBarIndicatorVisible="false" orientation="horizontal">
    <StackLayout orientation="horizontal" class="list-item__row inRight">
                <label *ngFor="let item of shoppingList" class="list-item"  text="{{ item }}"
                    textWrap="true"></label>
    </StackLayout>
</ScrollView>

Playground demo of the above can be found here.

marklanhamhc commented 5 years ago

@marklanhamhc it seems that using the Angular's 'ngFor' structural directive along with the NativeScript's StackLayout is causing this one in cases where the items does not have predefined size (e.g. Stacklayout with no width) and you are creating a dynamicly resized ScrollView which waits for the right sizes. We are currently investigating why the making and paddings are not applied as expected.

Meanwhile, as a workaround, you could create the same logic while directly using the Label component instead of StackLayout.

<ScrollView scrollBarIndicatorVisible="false" orientation="horizontal">
    <StackLayout orientation="horizontal" class="list-item__row inRight">
                <label *ngFor="let item of shoppingList" class="list-item"  text="{{ item }}"
                    textWrap="true"></label>
    </StackLayout>
</ScrollView>

Playground demo of the above can be found here.

I've tried setting the iosOverflowSafeArea to false by adding it to the top level ScrollView but this didn't make any difference. I also tried removing the <template> and <StackLayout> as you suggested and placed the *ngFor on the <label> but this didn't work either I'm afraid. I also tried setting a fixed height in the SCSS but this also made no difference.

marklanhamhc commented 5 years ago

...just to add, I've also tried removing all of the *ngFor references so its just the plain <StackLayout> and the problem still persists so it can't be to do with the *ngFor?

cerealexx commented 5 years ago

Yeah... I ended up testing plain StackLayout with static children Label and they still overlapped... It can't be an issue related to *ngFor

cremfert commented 5 years ago

Might this be related to this: #1593 ?

Best Chris

marklanhamhc commented 5 years ago

Might this be related to this: #1593 ?

Best Chris

Not quite, I have also tried adding iosOverflowSafeArea="true" to each element loaded in the <ScrollView> as you mentioned but this still doesn't work.

NickIliev commented 5 years ago

@marklanhamhc are you still having the issue with the linked Playground ?

marklanhamhc commented 5 years ago

@marklanhamhc are you still having the issue with the linked Playground ?

Yes, I viewed your Playground link but its still broken on my iPhone X:

image-1

I also tried editing the other sections to match the one you edited but ran into the same issues: https://play.nativescript.org/?template=play-ng&id=eGOyrq&v=15

thequiet commented 5 years ago

Same issue here. Update: Reverting my "tns-core-modules" did seem to solve the problem for me.

Just out of interest, what tns-core-modules version did you roll back to? And did you find that HMR still worked?

4.2.1, and yes it still worked.

marklanhamhc commented 5 years ago

Same issue here. Update: Reverting my "tns-core-modules" did seem to solve the problem for me.

Just out of interest, what tns-core-modules version did you roll back to? And did you find that HMR still worked?

4.2.1, and yes it still worked.

Ok, good to know. We did also try rolling back to 4.2.1 and whilst this fixed the iOS layout bug, we found another issue with our Lazy Loaded Modules not working with HMR, but this is a separate issue.

sivsushruth commented 5 years ago

Even I fixed it by rolling to 4.2.1 but have deal breaking bugs for android with 4.2.1

Any workaround to fix this with version 5 ?

NathanWalker commented 5 years ago

@NickIliev curious on this one - this seems to be a cascading serious breaking change with 5.0. ngFor in a ScrollView on {N} 5.0 on iOS is completely broken.

Is this anticipated to be fixed in an upcoming patch release/hotfix? Just curious if you all are aware of this or acknowledged there is a problem here (it's labeled question however this appears easily reproducible and breaking behavior) - definitely holding off updating to 5.0 due to this as well as not recommending to anyone to upgrade and sounds like many others are blocked by this due to comments.

jrz commented 5 years ago

Having layout issues too #1594

Also, when using the slider, it totally messes up the layout

jrz commented 5 years ago

Can confirm the slider issue was fixed when reverting to:

"tns-core-modules": "4.2.1",
MartoYankov commented 5 years ago

Hi guys, thanks for reporting these. I will be looking into this. There seems to be a problem with the ScrollView passing its size to its children in angular.

In the meantime, I applied iosOverflowSafeArea="false" to the 4 StackLayouts that hold the shopping lists and items laid out properly. Here is a link - https://play.nativescript.org/?template=play-ng&id=eGOyrq&v=17 .

sivsushruth commented 5 years ago

Okay, @MartoYankov I have figured out why this is happening

From tns 5, safeArea was introduced. What is happening is, if you checkout view.ios.ts, where we are readjusting the frame and assigning adjusted frame to native.frame. Refer: https://github.com/NativeScript/NativeScript/blob/master/tns-core-modules/ui/core/view/view.ios.ts#L174

If i just comment out those lines, and disable offset adjustment, everything works fine. This is especially a problem in list view, as multiple layouts passes cause an issue.

MartoYankov commented 5 years ago

@sivsushruth Yep, the property iosOverflowSafeArea controls this method. That is why setting it to false fixes the problem. However, the issue really is that the layout parameters are wrong. In this scenario there shouldn't be a need for adjustment.

sivsushruth commented 5 years ago

No, actually it does not solve problem when content is deeply nested, or inside list view etc. We cannot put iosOverFlowSafeArea for all components.

marklanhamhc commented 5 years ago

Yeah, understood @MartoYankov, the iosOverflowSafeArea="false" seems to be a good temporary fix but as you mentioned, "In this scenario there shouldn't be a need for adjustment". Hopefully you guys can get this fixed soon, thank you!

marklanhamhc commented 5 years ago

I see this task has been closed, does this mean the bug fix has been released into the latest version of Nativescript 5? If so, which version?

NickIliev commented 5 years ago

@marklanhamhc as of this moment the fix is currently in the master branch of tns-core-modules and can be tested with the next tag.

rm -rf node_modules platforms
npm i tns-core-modules@next --save
tns run android
cerealexx commented 5 years ago

Hey @NickIliev, after I updated to next everything seemed back to normal. But I think I found a new behavior related to this bug that is still affecting this version.

In iOS, if you are in a view that was affected by the old bug and you call a modal, after dismissing the modal, the view is again messed up with all the layouts overlapping.

cerealexx commented 5 years ago

Also happens when opening and closing a drawer. Layout is ok > open drawer > close drawer > Layout is messed up.

NickIliev commented 5 years ago

@cerealexx I've tested the case with RadSideDrawer and safe area but everything works as expected on my side. Make sure that you are using the latest version of nativescript-ui-sidedrawer and if the issue persists please provide a sample application that we can use for further investigations.

Update: the above is also valid for the modal view scenario (works as expected on our side) so additional details on how to reproduce the issue will be appreciated.

cremfert commented 5 years ago

Same here on an iPhone X: after opening a modal an closing it, the first element of a list view slides under the navigation bar and only half of its height is visible. I have to do keyboard input or click somewhere to refresh and correct the layout dimensions. There seems to be an issue with the refresh of a view: I'm having the same trouble with a scrollview (#1593), which only refreshed if I type some text in a textfield (don't know why). In both cases, I have to do a lot of messy code like programmatically scroll up and down to force a refresh or use refresh encapsulated in setTimeout code. This is really annoying as it shows no pattern for reproduction (it happens randomly) and hence we are really afraid to release our app for production.

MartoYankov commented 5 years ago

@cremfert Can you please open a new issue regarding this? Also, if you can provide some code sample, it would be great.

crowebird commented 5 years ago

FYI adding iosOverflowSafeAreaEnabled="false" to the ScrollView fixed this issue for me as it cascaded the disabling of OverflowSafeArea to all children. (using tns-core-modules 5.1.2)

SebastianCBA commented 5 years ago

Hi! I have the same bug, look: https://play.nativescript.org/?template=play-vue&id=MHVN2k&v=11

On Iphone (wrong): WhatsApp Image 2019-07-30 at 19 50 08

WhatsApp Image 2019-07-30 at 20 13 25

On Android (fine): WhatsApp Image 2019-07-30 at 19 12 52

Somebody can help me?

MartoYankov commented 5 years ago

@SebastianCBA I think the issue here is different - you have conditional layout inside the listview cells. On iOS this might result in unpredictable behavior. You should use multiple templates instead. See this example - https://play.nativescript.org/?template=play-vue&id=L8tcfY&v=23

SebastianCBA commented 5 years ago

@MartoYankov I have removed the conditions and the problem persists... also if I add conditions in v-template like:

<v-template if = "item.show == 1">

the application is broken

MartoYankov commented 5 years ago

@SebastianCBA I've also removed the conditions and the items laid out properly. See this playground - https://play.nativescript.org/?template=play-vue&id=MHVN2k&v=51. There is a weird behavior with scrolling. I believe the issue there is with the infinite scroll implementation. I don't think this is connected to the current issue. Please open a new one, so that we can take a look at it properly.