[TIMOB-20453] 5.3.0 Regression: "rendering artifact" between launch image and first view
| GitHub Issue | n/a |
|---|---|
| Type | Bug |
| Priority | Critical |
| Status | Closed |
| Resolution | Fixed |
| Resolution Date | 2016-08-03T03:36:50.000+0000 |
| Affected Version/s | Release 5.2.0 |
| Fix Version/s | Release 5.4.0 |
| Components | iOS |
| Labels | qe-5.2.1, qe-5.4.0, regression |
| Reporter | Fokke Zandbergen |
| Assignee | Hans Knöchel |
| Created | 2016-02-24T12:51:27.000+0000 |
| Updated | 2016-08-03T20:00:07.000+0000 |
Description
Attachments
| File | Date | Size |
|---|---|---|
| artifact.mov | 2016-03-02T08:40:52.000+0000 | 8947156 |
| fix.mov | 2016-03-02T09:13:11.000+0000 | 6523759 |
/cc [~cbarber]
I don't know that we can fix this. iOS controls when the launch screen starts to fade out. I'm not sure if this is triggered by the root view being displayed. Maybe we can render the launch screen again so that the launch screen essentially fades away to reveal the launch screen again. Part of the problem is storyboard launch screens are displayed differently than the old image-based launch screens. The image-based launch screens essentially sat there in the background and it appeared the root view rendered on top. I suspect that in order to solve this, we're going to have to do a nasty hack and it won't be as simple as making the root view transparent.
In light of this issue, storyboard launch files should have been listed as a Behavior Changed (not quite breaking, but pretty ugly) in your 5.2.0.GA release notes. Without adding the launch file tags or the background color tag, and using the old launch images, I get the fade-to-black "artifact" described here. It is pretty darned ugly. The best I can do is make that artifact white to match my launch image background, and live with a 1-2 second white screen during app launch. That's the case with or without using the launch image storyboard. In my opinion, this ticket should have a higher priority and should be a Bug not Improvement.
[~timpoulsen] are you sure the behavior has changed if you are not using the (off by default) storyboard launch file? I didn't notice and actually can't think of a reason why it would.
All I did was change the SDK version in the tiapp and on iOS I started seeing the 1-2 sec black "interstitial" screen. Since then, I've implemented the
enable-launch-screen-storyboardtag, the LaunchLogo images, and the color tag. I get the white interstitial now (this ticket). BTW, in my testing, it seems that if DefaultIcon-ios.png is present, the launch storyboards are used even without those tags or withenable-launch-screen-storyboardset to false. My old launch image files are not used if the DefaultIcon-ios.png file is present. (BTW, I'd swear that you used to have to name that file DefaultIcon-iphone.png but now it's DefaultIcon-ios.png)Just got a similar report on Stack Overflow: http://stackoverflow.com/questions/35706403/titanium-strange-transition-from-splash-screen-on-sdk-5-2-0 When I upgrade a 5.1.2 app of mine to 5.2.0 I notice no difference. Also looking at the [source code](https://github.com/appcelerator/titanium_mobile/blob/1a4d814dffb007bb9eda47687ceb4f8d5b066590/iphone/cli/commands/_build.js#L2109) storyboard launch files will be disabled if you don't have the flag in
tiapp.xmland is also unrelated to having aDefaulticon-ios.pngfile. That said, these reports can't be coincidence. I've asked [~developer82] to provide a reproducible test case.I can confirm this too, every settings (either turn on/off flag or totally don't have the flag in tiapp.xml) will cause a short black screen when I launch my app, normally appear after I build the app to device [Update] Sorry, I think I made a mistake, I put the flag under plist tag. After change it to the right place (under ios tag), so far everything works as expected.
I was able to reproduce this. Just created a new Ally project. [redacted: added simple example to description]
Fokke, You made my day! This works fine in my case.
PRs approved and merged!
Verified as fixed, Using SDK
5.2.1.v20160307134704the behaviour of the app matched the "fix.mov" video. When Storyboard is set to *false*, launchImage is shown & there is no rendering artifact. When Storyboard is set to *true*, the launchImage is not shown. Tested on: iPhone 6S (9.2.1) Device Mac OSX El Capitan 10.11.3 (15D21) Ti SDK: 5.2.1.v20160307134704 Appc Studio: 4.5.0.201602170821 Appc NPM: 4.2.4-2 App CLI: 5.2.1-11 Xcode 7.2 Node v4.2.6 production *Closing ticket.*Hello, The issue is back in SDK 5.3.0.GA. I can reproduce the issue in iOS 9.2. Environment:
Operating System Name = Mac OS X Version = 10.11.4 Architecture = 64bit # CPUs = 4 Memory = 8589934592 Node.js Node.js Version = 4.2.2 npm Version = 2.14.7 Titanium CLI CLI Version = 5.0.8 Titanium SDK SDK Version = 5.3.0.GA SDK Path = /Users/gsl001/Library/Application Support/Titanium/mobil esdk/osx/5.2.2.GA Target Platform = iphoneYour SDK Version says 5.3.0.GA, but your SDK Path shows 5.2.2.GA
I opened a new bug about it in 5.3.0, and since it's duplicated with an old bug it was reopened. I have this problem with 5.3.0.
[~developer82] wat is the ticket nr of that new bug report?
It was a new bug report. Someone marked it as duplicated and pointed here. Changing this bug to ReOpen
Any updates on this? I started to notice the black screen as well when I updated to 5.3.0
Ok, so just to clarify: You are sure that the rendering-artifact (aka black screen) did not happen in 5.2.1.GA but it does on 5.3.0.GA? That is very important for the investigation, thanks!
I had upgraded from 5.2.2.GA to 5.3.0.GA and that was when the black screen occurred for me.
Hans, Yes I'm sure. It was a bug in 5.2.0 that was fixed in 5.2.2 (see reproduction of bug in this post). And now it's back in 5.3.0.
[~developer82] I tested using 5.2.2.GA and I see the same behavior with LaunchScreen enabled. The problem is (as above described) that iOS decides when to hide the launch screen, so we would need to apply a hack that shows it until the app is ready to launch - after our initial operations are done. Tricky ...
Alright, I guess I finally found the correct place to inject the storyboard. It basically uses the view of the launchscreen-storyboard if it is defined, and the usual view if not. The view is garbage-collected after being presented, so the performance is the same. PR (master): https://github.com/appcelerator/titanium_mobile/pull/8102 PR (5_4_X): https://github.com/appcelerator/titanium_mobile/pull/8103 Test: 1. Run
appc newto create a new project. This enabled storyboard automatically. If you choose this step, you can proceed to step *4*. 2. Include<enable-launch-screen-storyboard>true</enable-launch-screen-storyboard>in the<ios/>section of your tiapp.xml 3. Provide aLaunchScreen.storyboardfile inplatform/iphone4. Open the app.js and paste the following code into it:var win = Ti.UI.createWindow({ backgroundColor: 'green' }); // simulating a delay when you need to do heavy stuff before opening the first window setTimeout(function() { win.open(); }, 3000);CR and FT passed. 5_3_X backport please.
PR (5_3_X): https://github.com/appcelerator/titanium_mobile/pull/8106
PR Merged.
The PR introduced a new bug.
Steps to reproduce
1. *appc new* 2. in tiapp.xml, set<ios> <enable-launch-screen-storyboard>false</enable-launch-screen-storyboard> <use-app-thinning>false</use-app-thinning>Expected Result
App builds and runs normallyActual Result
App crashes with the following log:[ERROR] The application has crashed with an uncaught exception 'NSInvalidArgumentException'. [ERROR] Reason: [ERROR] Could not find a storyboard named 'LaunchScreen' in bundle NSBundle </Users/kiat/Library/Developer/CoreSimulator/Devices/7C85302F-79EB-4187-B8B2-EA13F9D69D1C/data/Containers/Bundle/Application/4940E038-AF33-437A-88B3-84FBEACE5D74/SGTestLaunch.app> (loaded) [ERROR] Stack trace: [ERROR] [ERROR] 0 CoreFoundation 0x00000001064a2d6d __exceptionPreprocess + 141 [ERROR] 1 libobjc.A.dylib 0x0000000105e70deb objc_exception_throw + 48 [ERROR] 2 UIKit 0x0000000102b76d3d -[UIStoryboard name] + 0 [ERROR] 3 SGTestLaunch 0x000000010054e8ff -[TiRootViewController loadView] + 319 [ERROR] 4 UIKit 0x00000001025cf560 -[UIViewController loadViewIfRequired] + 138 [ERROR] 5 UIKit 0x00000001025cfcd3 -[UIViewController view] + 27 [ERROR] 6 UIKit 0x00000001024a5fb4 -[UIWindow addRootViewControllerViewIfPossible] + 61 [ERROR] 7 UIKit 0x00000001024a669d -[UIWindow _setHidden:forced:] + 282 [ERROR] 8 UIKit 0x00000001024b8180 -[UIWindow makeKeyAndVisible] + 42 [ERROR] 9 SGTestLaunch 0x0000000100610b15 -[TiApp initController] + 181 [ERROR] 10 SGTestLaunch 0x0000000100611ec0 -[TiApp application:didFinishLaunchingWithOptions:] + 304 [ERROR] 11 UIKit 0x000000010242b9ac -[UIApplication _handleDelegateCallbacksWithOptions:isSuspended:restoreState:] + 272 [ERROR] 12 UIKit 0x000000010242cc0d -[UIApplication _callInitializationDelegatesForMainScene:transitionContext:] + 3415 [ERROR] 13 UIKit 0x0000000102433568 -[UIApplication _runWithMainScene:transitionContext:completion:] + 1769 [ERROR] 14 UIKit 0x0000000102430714 -[UIApplication workspaceDidEndTransaction:] + 188 [ERROR] 15 FrontBoardServices 0x0000000108edf8c8 __FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK__ + 24 [ERROR] 16 FrontBoardServices 0x0000000108edf741 -[FBSSerialQueue _performNext] + 178 [ERROR] 17 FrontBoardServices 0x0000000108edfaca -[FBSSerialQueue _performNextFromRunLoopSource] + 45 [ERROR] 18 CoreFoundation 0x00000001063c8301 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 [ERROR] 19 CoreFoundation 0x00000001063be22c __CFRunLoopDoSources0 + 556 [ERROR] 20 CoreFoundation 0x00000001063bd6e3 __CFRunLoopRun + 867 [ERROR] 21 CoreFoundation 0x00000001063bd0f8 CFRunLoopRunSpecific + 488 [ERROR] 22 UIKit 0x000000010242ff21 -[UIApplication _run] + 402 [ERROR] 23 UIKit 0x0000000102434f09 UIApplicationMain + 171 [ERROR] 24 SGTestLaunch 0x0000000100442806 main + 310 [ERROR] 25 libdyld.dylib 0x00000001078bb92d start + 1 [ERROR]Can no longer reproduce on 5_4_X. Environment used: Ti SDK 5.4.0.v20160712013704 Appc cli 5.4.0-31 Appc npm 4.2.7 Scenarios tested:
Verified as fixed for alloy I have opened TIMOB-23673 for the issue with classic projects. I also tried to set LaunchScreen.storyboard on a 5.2.0 classic project which did not show the LaunchScreen.storyboard either. Tested on: iPhone 6 plus (9.1) iOS Simulator (9.3) Mac OSX El Capitan 10.11.6 Studio: 4.7.0.201607130543 Ti SDK: 5.4.0.v20160720201924 Xcode 7.3.1 Appc NPM: 4.2.7 Appc CLI: 5.4.0-33 Node v4.4.4 * Closing Ticket*
I would like to reopen this issue to provide a PR I thought about that fixes an outstanding issue / edge-case where the storyboard remains the rootView when the default containers are empty. Reproduce in the current master / 5_4_X:
setTimeout(function() { var tabGroup = Ti.UI.createTabGroup(); tabGroup.open(); }, 2000);Approved! Tested with enable-launch-screen-storyboard true and false.
I ran the following Demo code as above:
setTimeout(function() { var tabGroup = Ti.UI.createTabGroup(); tabGroup.open(); }, 2000);[ERROR] : Script Error { [ERROR] : column = 38; [ERROR] : line = 2; [ERROR] : message = "invalid method (createTabGroup) passed to UIModule"; [ERROR] : sourceURL = "file:///var/containers/Bundle/Application/7E28E987-6749-4850-99CE-63CBD674CD67/TuesTay2.app/app.js"; [ERROR] : stack = "[native code]\nfile:///var/containers/Bundle/Application/7E28E987-6749-4850-99CE-63CBD674CD67/TuesTay2.app/app.js:2:38"; [ERROR] : }[~htbryant] What I understand from the ticket is that the main issue is the "rendering artifact" when launching an app. The first PR indeed solved the bug in general, where the first window opened is a Ti.UI.window. But Hans forgot to address the same issue where a tabGroup is opened initially instead. The problem is the demo code provided. It's one line of code with no real tabs and windows being added to the tab group, causing that error you see, completely unrelated to this ticket. I used the classic template when i did appc new so i never used that demo code when i reviewed this. Here's a link to the issue you are seeing., https://archive.appcelerator.com/question/148213/super-urgent--invalid-method-createtabgroup-passed-to-uimodule Now, the real test steps is here: 1. *appc new --classic* 2. in tiapp.xml,
cmd-T4. *appc run -p ios*Expected result
no artifact when during launch. you'll see our favourite red splash screen If you use an older 5.4.X build like 5.4.0.v20160519143319. It will crash. This 2nd PR fixes that. *Note* if you switch around often the true/false for[~cng] Thank you for the clarification. I have created a separate ticket (see TIMOB-23721) in regards to the aforementioned issue encountered with tabGroup() and followed the test steps as stated. Verified as fixed for both