I just googled the devices and seems like your iPod touch is similar to my iPhone4 with less memory. Reference - Click here
So my guess is that if anything you will see the issue sooner than I do which is even better. I usually manage to get the crash on the 4th or 5th open close. Please go ahead and test if you have the time. Thanks so much!!!
Here are my explanations about the list:
(1) It’s always on top. The app cannot detect user swipes when webView is there. The app cannot show some menu on top of the webView.
If it’s always on top, I cannot put any menu on top of it. The modern apps that has embedded web browsers can place menu or some user action buttons on top of it. They can also detect user gestures. And we cannot do anything. The webView seems very “un-advanced” to users.
(2) The loading event for iOS is sometimes missing.
Although this bug has been claimed as fixed, I have found it’s still missing in some case from my testing. I have been stating this in the other forum post, but it’s ignored and nothing happens.
(3) There is no 100% way to tell what the current URL is.
Because of (2), if the loaded event is not 100% there (besides, what if the Internet connection is lost before generating the loaded event), how to determine the current URL is? To know the current URL is the basic step to share the current link to other apps or to open it from Safari.
(4) The webView gives blank screen for some links.
Although it does not happen often, I have been encountering this for a few times when you click some internal links in some web pages, it does not go anywhere but a blank screen. And if I try to open the same web pages in Safari, it works well.
(5) The webView does not load pages fast enough comparing to Safari/Chrome.
My app is a reader app so my users use the webView heavily. I have received several complaints (let alone these who keep silent) about my webView loads slower than Safari, which gives bad user experience. I have tried this too. I think the speed is almost the same, however Safari shows some page content first before the loading is finished, and our webView shows the whole page content once it’s finished loading. It’s quite obvious to feel our webView is slower from a user’s perspective. Besides, without a progress indication (although there is a spinner), the waiting time feels longer.
(6) The webView cannot show loading progress indicator because there is no way to know the progress
A loading progress indicator will give better user experience.
(7) The webView cannot share to other apps, such as Evernote, etc.
The modern apps that use embedded web browsers today all have the sharing feature to other apps. Although we have Facebook/Twitter/Weibo/Email/Message sharing, but we have to implement them one by one and there are more sharing options (to other apps, Evernote is just an example). Besides, as explained in (1), the webView is always on top, I cannot show a sharing menu on top of it, which is very odd. I am using “system alert” now to show a text sharing menu at this moment, which looks very “un-advanced”. On the other hand, why not make this sharing feature to be included in webView? So every Corona users who use webView can have it instantly? because every embedded browser today has such a “basic” feature that is implemented in a nice & advanced way.
(8) a new-found bug: changing webView rotation and then its width (in order to support device orientation) doesn’t work as expected
I have been using webView in Portrait mode. It’s a very nature & basic feature to show webView in landscape mode while the device orientation changes. However when I try to implement it, I found I can’t because of the bug. Unless I am doing something wrong (I have asked it in another forum post but no response), I think it’s a bug that need to be taken care of asap.
I just tested this on my iPod Touch 4th-gen using iOS 6.1.5. I cannot get it to crash. However, I am able to crash the sample biz app on my iPhone5 using iOS7, but only when I “< Back” out of a web view which is still loading (i.e. one of the Corona Geek ones which takes longer to load because they have an embedded YouTube video in them). While that was loading, if I hit the widget “< Back” button, it crashes fairly reliably.
Does this sound like what you or others are seeing?
Unfortunately I can’t test on the iPod Touch 4th-gen with iOS7, because Apple won’t let me upgrade to iOS7 on that device (I guess they consider it just a bit too old).
Brent
This sounds like exactly the same issue I was seeing. You also proved it’s not due to lower resources on iphone4. Thank you.
Joe. thanks for the list. It’s a good reference to some of the pain points the community is feeling with webViews. We’ve been talking with Engineering about this and I’ve got some feedback so I can answer some of these for you. There are a few that we need bug reports on (that after talking with engineering don’t seem to exist).
2 - 3. I think this is the bug we fixed, but reports are that it is not completely fixed. I saw a bug report that looks similar to this, but it wouldn’t hurt to have one. Keep in mind that we need a complete projects (main.lua, build.settings, config.lua) that shows the issue. We can’t recreate your build.settings and config.lua which may impact the testing.
We need to know what links is generating a black screen and it would be best to have this in the form of a bug report so the engineers will have all the information they need.
Speed: We are calling the native SDK’s provided by the operating system for this to do the work. Corona is really out of the loop there. I’m speculating here, but the browsers may have additional features like caching that the OS doesn’t grant to webViews.
6. seems related to #2 above.
There is some confusion on what you’re asking for here. Is this related about trying to draw things on top of the webView?
I believe we have a bug report on this.
Rob
Rob, can you kindly confirm whether we need a bug report for the bug you were not able to duplicate but Brent managed to later on? Since in 2100 it does not seem to crash in this manner I see this as a regression bug. CL sample code is where it’s seen so a bug report at this point seems like unnecessary work to me. Regression bugs should take priority right? Thanks
That bug has been filed.
Rob
Love it when you say that! :)
Thank you very much!
So happy there’s been some traction with this issue.
@Brent: I can confirm iPod Touch 4g with iOS 6.x as well (iOS7 not possible, as you stated). I have an iPad mini (non-retina) and iPhone 5 that also have the same issue.
Thanks for the detailed response.
If it is the way it is & nothing can be done, I have to say Corona webView provides basic functionalities only. And my conclusion is that apps that really use & depend embedded browsers a lot, like a news reader app, should not be built with Corona. I think I have to go with XCode if I want to put my news reader app into another level. I will use Corona for games only or business apps that don’t require an advanced embedded browser at all.
Take a look at modern news apps like Flipboard & recently-launched Facebook Paper, their embedded browsers are where the trend is going. I had hoped I could do something similar with Corona for the embedded browser.
Is this fixed? My webview crash sometimes when I trying to remove the webview before the web has been completely loaded on iOS 7.
I am using Corona Build 2014.2152 and I had this problem on iPad 3 iOS 7.0.4.
Daily build 2174 seems having fixed this issue?
- iOS/Mac: Resolving issue when closing/removing WebView from scene casenum:25975, 28771, 27995, 28729
If you have the issue (I can’t reproduce it somehow), maybe you want to verify it… & post some result here… would like to know if everything goes better for webView.
Thanks.
It works for me using daily build 2174
No crashes using Daily Build 2174, yeah and thanks!
I’ve just found that we are still having the same issue, I’m currently using build 2182 (I would update it but with any luck we will be releasing soon so I’d rather not risk an update breaking something).
Although we do use storyboard, I’m calling the webview as a sort of overlay to the scene. I have 2 buttons, one which calls the webview, and another which dismisses it and calls up some other stuff.
At the point where I remove the “overlay”, I call the following:
if webView then webView:stop() webView:removeSelf() webView = nil end
I don’t call webView:removeEventListener( “urlRequest”, webListener ) at the moment because I also don’t add any listener to it (I did before, but it was just this and so had no real use:
local function webListener( event ) if event.url then print( "You are visiting: " .. event.url ) end if event.type then print( "The event.type is " .. event.type ) -- print the type of request end if event.errorCode then native.showAlert( "Error!", event.errorMessage, { "OK" } ) end end
If I press my callWebview button, and then quickly press the dismiss button I get a seg11 fault. This is on an iPad 3, it never happens on Android. It’s clearly a similar problem to the one mentioned before, the webView:request function is receiving it’s reply after the webview has been dismissed, but shouldn’t webview:stop() pick that up?
Now using SDK 2014.2260 and we are still getting the same problem. I’ve added the urlRequest listener back in, and removed it when I remove the webview:
if webView then webView:stop() webView:removeEventListener( "urlRequest", webListener ) webView:removeSelf() webView = nil end
but still we end up with a segmentation fault if we open and close it quickly.
Can you produce a small app that demos the problem still? This is the first set of complaints about this in a while.
I’ve just found that we are still having the same issue, I’m currently using build 2182 (I would update it but with any luck we will be releasing soon so I’d rather not risk an update breaking something).
Although we do use storyboard, I’m calling the webview as a sort of overlay to the scene. I have 2 buttons, one which calls the webview, and another which dismisses it and calls up some other stuff.
At the point where I remove the “overlay”, I call the following:
if webView then webView:stop() webView:removeSelf() webView = nil end
I don’t call webView:removeEventListener( “urlRequest”, webListener ) at the moment because I also don’t add any listener to it (I did before, but it was just this and so had no real use:
local function webListener( event ) if event.url then print( "You are visiting: " .. event.url ) end if event.type then print( "The event.type is " .. event.type ) -- print the type of request end if event.errorCode then native.showAlert( "Error!", event.errorMessage, { "OK" } ) end end
If I press my callWebview button, and then quickly press the dismiss button I get a seg11 fault. This is on an iPad 3, it never happens on Android. It’s clearly a similar problem to the one mentioned before, the webView:request function is receiving it’s reply after the webview has been dismissed, but shouldn’t webview:stop() pick that up?
Now using SDK 2014.2260 and we are still getting the same problem. I’ve added the urlRequest listener back in, and removed it when I remove the webview:
if webView then webView:stop() webView:removeEventListener( "urlRequest", webListener ) webView:removeSelf() webView = nil end
but still we end up with a segmentation fault if we open and close it quickly.