Skip to content
This repository has been archived by the owner on Jan 9, 2023. It is now read-only.

Possible Race Condition on iPhone 11 Pro on Start Up #138

Closed
3 tasks done
vinnichase opened this issue Mar 29, 2020 · 17 comments
Closed
3 tasks done

Possible Race Condition on iPhone 11 Pro on Start Up #138

vinnichase opened this issue Mar 29, 2020 · 17 comments

Comments

@vinnichase
Copy link

Bug Report

Problem

Our customers report random white screens on app launch on iOS devices. While almost all devices happen to launch the app successfully after some retries the iPhone 11 Pro always starts with a white screen. That got me (after long blackbox digging) to the assumption that fast iPhones have the Problem and that WKWebView maybe starts with a race condition.

On my iPhone 11 Pro simulator I luckily got a 50/50 chance of a white screen so I started debugging CDVWKWebKitViewEngine.m. I have absolutely no knowledge in Objective-C so I just restarted over and over again to spot randomly the differences in the call stack. While doing this I slowly got an understanding of how the plugin might be working under the hood. userContentController:didReceiveScriptMessage seems to play a role in the successful startup of the container and all scripts and assets being loaded.

After a long time I recognized that breaking the code at line 321 in CDVWKWebKitViewEngine.m got the app working constantly in the simulator which brought me adding a sleep timer in line 321:

- (id)forwardingTargetForSelector:(SEL)aSelector
{
    [NSThread sleepForTimeInterval:1.0];
    return _engineWebView;
}

That at least got the app starting without breakpoints in the simulator. However on the physical device it kept the white screen.

I will now go on debugging to spot another point. But any help or hints are highly appreciated.

What is expected to happen?

App should start correctly after splash screen.CDVWKWebKitViewEngine.m -> userContentController:didReceiveScriptMessage should be fired on every App start reliably.

What does actually happen?

userContentController:didReceiveScriptMessage is only fired on iPhone 11 Pro Simulator, iOS 13.3 when [NSThread sleepForTimeInterval:1.0]; is added in line 321 in CDVWKWebKitViewEngine.m:

- (id)forwardingTargetForSelector:(SEL)aSelector
{
    [NSThread sleepForTimeInterval:1.0];
    return _engineWebView;
}

Without adding the sleep line I encounter a white screen in 5 out of 10 cases in the simulator. userContentController:didReceiveScriptMessage is not fired in those cases.

On physical iPhone 11 Pro, iOS 13.3.1 the app launches constantly with a white screen after splash and
userContentController:didReceiveScriptMessage is not fired - even if I set the sleep to 5 seconds.

Information

Command or Code

Environment, Platform, Device

  • iPhone 11 Pro Simulator, iOS 13.3 (App starts after 1 sec sleep hack)
  • iPhone 11 Pro, iOS 13.3.1 (Still broken)

Version information

Cordova:

  • 9.0.0 (cordova-lib@9.0.1)
  • cordova-plugin-camera: 4.1.0
  • cordova-plugin-device: 2.0.3
  • cordova-plugin-dialogs: 2.0.2
  • cordova-plugin-file: 6.0.2
  • cordova-plugin-media-capture: 3.0.3
  • cordova-plugin-statusbar: 2.4.3
  • cordova-plugin-wkkeyboardfix: 1.0.1
  • cordova-plugin-wkwebviewxhrfix: 0.1.0

React:

  • onsenui: 2.10.8
  • react: 16.8.6

XCode: 11.3.1
MacOS Catalina 10.15.4

Checklist

  • I searched for existing GitHub issues
  • I updated all Cordova tooling to most recent version
  • I included all the necessary information above
@JamalAPI
Copy link

JamalAPI commented Mar 30, 2020

Just wondering, are you missing the following in config.xml?

<preference name="SplashScreenDelay" value="1000"/>

Also, I do not see cordova-plugin-splashscreen v5.0.3 listed in your plugin list.

@vinnichase
Copy link
Author

Is the splashscreen plugin necessary for the application to load? However I migrated to capacitor due to the very low maintenance of cordova so I can close this issue.

@washowasho
Copy link

Hi - Any update on this? I am having the same exact issue. It seems that the white screen appears for me only when <preference name="WKWebViewOnly" value="true" /> is included in my confix.xml. Once I remove it... the app works.

@vinnichase
Copy link
Author

vinnichase commented Apr 3, 2020

Do yourself a favour and migrate to ionic capacitor if possible. Its much easier to set up, its compatible with cordova plugins and its still maintained properly. That whitescreen of death will only get worse with each new iOS version.

Once I remove it... the app works.

I assume this will enable UIWebView again which is announced to be rejected in the AppStore from April 2020.

@JamalAPI
Copy link

JamalAPI commented Apr 3, 2020

Hi - Any update on this? I am having the same exact issue. It seems that the white screen appears for me only when <preference name="WKWebViewOnly" value="true" /> is included in my confix.xml. Once I remove it... the app works.

This means you are not using the proper config.xml settings or a plug you are using is causing the issue.

See: https://cordova.apache.org/howto/2020/03/18/wkwebviewonly.html on proper configuartion.

If you are using Onsen, make sure you call:

ons.fastClick.destroy();

in oDeviceReady()

If using Monaca.io, see the following:

Select "Configure -> App Settings for iOS" from the IDE header menu and update the item "WebView Engine" to "WKWebView".
For the build environment, select the menu "Build-> Build Environment Settings..." and set "iOS 5.1.1" and "Xcode 11.3".
Select "Configure -> JS/CSS Components Settings..." and update Monaca Core Utility to version 2.1.0
Select the menu "Build-> Build App for iOS ..." and start building with the custom build debugger.

Source: https://monaca.io/headline/index.html

@JamalAPI
Copy link

JamalAPI commented Apr 3, 2020

Is the splashscreen plugin necessary for the application to load? However I migrated to capacitor due to the very low maintenance of cordova so I can close this issue.

Not sure about your exact setup, but making a statement like that is not helpful when there is in fact lots going on in Cordova, see: https://cordova.apache.org/blog/

@vinnichase
Copy link
Author

vinnichase commented Apr 3, 2020

OK! then forgive me my passive agressive statement, it was due to days of long and frustrating trial and error. Including all combinations of fixes(yes also fastclick.destroy) from the few information that I found on those very specific problems.

My builds remained failing randomly on all the possible iOS devices, when I got it working on one it started something strange on another. In the end I reflected that this should not be the development experience and I switched to capacitor which does everything cordova did right but has leaner xcode and android studio projects (just as I always wished from cordova) and helps much better to get a foot into the native API and custom native code. And its true when critical plugins like this have about 10 issues from 2019 which haven't been answered yet and a JIRA board with half of the issues in "won't fix" state there is a clear lack of maintenance.

Thats only my personal opinion and I indeed wanted to help you with my recommendation to migrate. I know depending on the app size migration can be a terrifying imagination. In my special case it solved this problem and every other quirks that I procrastinated to just get the critical functionality of my app working. I did the migration of the whole project on both platforms in half a day including the plugins which was totally worth it compared to the previous two weeks of headache. See also apache/cordova#163. At least it's not a waste of time to start a small capacitor sample app.

However I can understand if your app is heavily dependent on many cordova plugins. Then migration would be a huge pain. Unfortunately i'm not the right one to help in this case but would leave the issue open for discussion.

@timbru31
Copy link
Member

timbru31 commented Apr 6, 2020

Is this reproducible in a new, plain Cordova app? A minimal reproduction repository would really help to debug and later fix this issue. More information on how to create one: https://github.com/apache/cordova-contribute/blob/master/create-reproduction.md

@saqib-dev
Copy link

Facing the same issue White Screen appears after upgrade UIWebView to WKWebView Plugin #141 . Please help to resolve this issue.

@saqib-dev
Copy link

@timbru31 issue is with ios 13 version with WKWebView

@timbru31
Copy link
Member

timbru31 commented Apr 6, 2020

That’s not what we’ve asked for.

@7underlines
Copy link

7underlines commented Apr 7, 2020

I've got this behaviour yesterday. The error in the XCode log field was something like "ERROR ... ready not defined".
I've tried all workarounds listed here, nothing worked. I can't publish the app because apple forbids it since 1.4.2020 with old UI Webview. Is there anything other to try?

@timbru31
Copy link
Member

timbru31 commented Apr 7, 2020

Again, writing "I'm having the same problem" does not help to debug the issue. We need a reproducible example in a plain Cordova app.

@vinnichase
Copy link
Author

I think we have a problem with time pressure here. People are forced to migrate and have no time to provide a minimum example. Can you maybe use my sleep hack as a hint where the unstable behaviour in the native bridge happens?

@saqib-dev
Copy link

@timbru31 reproduction repository has been created, please fetch the below repository.
https://github.com/saqib-dev/Cordova-WKWebView-Upgrade

@saqib-dev
Copy link

@timbru31 Issue reproduced repository is created. Can you get the checkout and assist to resolve the issue ?

@jcesarmobile
Copy link
Member

We are archiving this repository following Apache Cordova's Deprecation Policy. We will not continue to work on this repository. Therefore all issues and pull requests are being closed. Thanks for your contribution.

@jcesarmobile jcesarmobile closed this as not planned Won't fix, can't repro, duplicate, stale Jan 8, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants