-
Notifications
You must be signed in to change notification settings - Fork 991
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(ios): improve webview background experience #2933
Conversation
3bcb502
to
50a5040
Compare
This looks good to me but I will leave it for @jcesarmobile to review. This also updates the default launch storyboard template to set a background color on the image view. That was not set before which means that any transparency in a splash image would fall through to an undefined color and render as black. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added a minor recommended change since we use 2 spaces instead of 4.
I think changing the opaque value should be behind a preference, since it can mess with a few plugins that set opaque to false on their initialization and this change will set it to true when the page finish loading, breaking their functionality.
And also because this change is not needed for everybody, the flash is noticeable when the splash plugin is not used (if using "launchShowDuration": 0
), if the splash plugin is used and hidden when the app content is loaded, there is no flash.
And for the storyboard changes, they are not needed neither, it works fine if using transparent background images, but I think we should encourage users to use dedicated light/dark splash images without transparent backgrounds. But since it's a template change and will only affect new apps and only if they use transparent background images, I don't mind if we add it.
@jcesarmobile I'm not sure a setting is the right solution. Would the setting be to make the web view non-opaque on initial load (and then set it back), or would the default behavior be to make it non-opaque and the setting controls whether or not it gets set back? If it's the first, then you wouldn't be able to set it AND use one of the plugins that expects the change to persist. If it's the second, it's potentially a breaking change for anyone using one of those plugins now. So, I don't think making the opacity flag a setting is what's needed and there's an alternate approach. Here's a timeline of the app starting up:
This change to Instead of just overwriting That should prevent any conflicts with plugins and any apps that keep the splash screen up until step 5 won't notice. I would argue that the real issue is that plugins should not be modifying a global property like the webview's |
…al load and preserve the value in case it was modified by a plugin.
Co-authored-by: jcesarmobile <jcesarmobile@gmail.com>
…m/capacitor into webview-background-enhancments
Based on a few different posts from the forum, the configuration for how the webview handles backgrounds can lead to a flash of white when starting up, especially in dark mode.
This PR attempts to improve this by first
isOpaque
There could be room for further improvements, but I think this is a good first step.