| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
test --ignore uitests_android ngapps_android api19 api23 api28 |
Sorry, something went wrong.
|
test --ignore uitests_android ngapps_android api19 api23 api28 |
Sorry, something went wrong.
|
test ngapps#svetoslavtsenov/enable-naviagtion-tests-android build_nativescript_angular#svetoslavtsenov/enable-naviagtion-tests-android |
Sorry, something went wrong.
|
test ngapps#svetoslavtsenov/enable-naviagtion-tests-android build_nativescript-angular#svetoslavtsenov/enable-naviagtion-tests-android |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Fixes: #6490
Related to: #6339
Related to: #6421
This fix was originally applied with #6339 but was later reworked with #6421 (basically the part in frame.android.ts where disposing the fragments is performed after super.unloaded(...) logic).
The original fix did not work properly when called in onDestroyView(...) as it essentially removed the fragment view too early hence breaking exit transition. I actually tested onDestroy(...) then as well but due to a different bug addressed with #6421 and #6489 (essentially we need to cache and restore animators because of the simulated first navigation) onDestroyView(...) and onDestroy(...) were called at the same time (now onDestroy(...) is called after the actual exit transition is finished which means we can use it to detach the native view from its parent).