@joe528, I’ve tried putting the removeEventListener damn near everywhere. I’m still able to crash the webview, even if I wait for a loaded event before re-enabling the button. This is a really bad crash that we can’t seem to work around. I’ll post anything else I find, but as of now I’m at a loss. Any other input/suggestions would be greatly appreciated.
Do you mean it crashes in Simulator?
I have found the webView would crash in simulator for certain web pages, no matter what.
However, it does not crash in actual devices. Therefore, I ignore this problem for Simulator.
I didn’t report this crash for the Simulator because I hope Corona can spend more time to enhance webView from the ground.
I ended up finding a workaround, but the bug remains.
What’s the workaround? What bug remains?
Do you have the crash in Simulator or/and actual devices?
Thank you very much for this thread. I started trying out the newWebView API (as opposed to showWebPopup which I used to use) and came up with this exact same issue. Segmentation fault: 11 in my console. Crash after 5 consecutive loads, moving in & out of scene etc. I will try the suggested methods to cope. Hope there is a more robust solution along the way. Thanks.
I ended up working around this by doing the following:
In my button handler for closing the overlay scene, I stop the webview and attempt to remove the event listener:
[lua]
webView:stop()
webView:removeEventListener(‘urlRequest’, listener)
[/lua]
I then have to add an artificial delay to the exit of my overlay:
[lua]
timer.performWithDelay( 200, function()
storyboard.removeOverlay()
end)
[/lua]
And finally in my exitScene:
[lua]
webView:removeSelf()
webView = nil
[/lua]
I hope that helps anyone else trying to use webViews.
Great guidance. Thank you very much trying it right now.
Thanks for the sharing the workaround
But I really don’t like the delay… Although only 200ms, it’s still not a good UI experience. Besides, Corona should fix this.
Do you see the crash in Simulator? Is your workaround applied to Simulator?
By the way, is it stable on the latest dailies for you? My previously working app (using showWebPopup) was acting funny in the later dailies and hence my diving into the new API but now I’m not seeing consistent results here either. Going back to 2100 to see how it works there. So for clarity, can you kindly let me know which build you’re on and whether your experience is rock solid? Thanks
Edit - Took my old code using showWebPopup back to 2100 and it is rock solid once again. Something is not right on later builds but I don’t know how to report this. Anyways its off topic for this thread.
Yup. Confirmed. I built two versions of the Business App Sample. One on build 2100 and one on build 2159. Build 2159 consistently crashes when I tap the entries on the Blog page loading one, closing it and going to the next one. 2100 is able to go through all without crashing. Anyone else seeing this?
I just tried tapping on the rows in the tableView and then hitting the back button, then tapping on another row then hitting the back button with 2156 and got no crashes. I think I have a bug in the event handling because if I click a link, weird things happen. Are you seeing this on device or in the simulator? Are you doing something other than clicking the tableView row and then the back button?
Rob
Built for device. Running on iPhone4 IOS 7.04
Tap first 2 entries, wait for load tap back
tap 3rd entry - halfway through this will fire off mobile safari and start loading youtube
close mobile safari go back to business app sample
you will see the webview loading. Hit back --> crashes on my device.
Same process not crashing on build 2100. Not sure whats different. Will try 2156 if you can try and confirm all is well. Thanks
Here are my observations about the webView crash:
(1) For Simulator, when accessing certain web pages (URLs), it always crashes, no matter what, regardless old or new versions of Corona. Therefore, I have been asking max84 if he is seeing the crash in Simulator or not, but he has not responded this question directly.
(2) For actual devices, webView does NOT crash in early Corona build (I started using webView in Aug though). But since September (my first post date), I found webView built with new Corona versions always crashes in actual devices. However, by using the workaround I provided in my earlier post, I don’t see any crash in actual devices even with the latest builds.
I hope this can clarify things a bit.
Therefore, I think if we want to talk about webView crash, let’s first to separate the problem to see if it’s a Simulator or actual device.
This is a concern isn’t it? If it wasn’t crashing pre-September and now is crashing unless workarounds are used then this is something CL should fix. Isn’t September the point when G2 was introduced? Perhaps this is a post G2 issue. Thoughts?
I tried to reproduce what Kerem did and on my iPhone 5 (7.0.4) I can’t crash it. I’ll keep looking at it to see if I’m doing something weird with how I’m dealing with the webView.
Rob
Rob, I think the device makes a difference. I saw references to iPhone 4S earlier in this thread. I can’t duplicate the issue on iPad mini either. Seems like this issue (if it exists) might be affecting older devices with lower resources or something like that. Do you have access to an iPhone 4?
Of course, it is a concern and I “hoped” Corona to fix it. Here is my earlier comment after I found the workaround:
It still feels tricky & unstable, is it possible to be fixed at Corona side?
I am still hoping Corona can pay more attention to webView and Corona should also consider a full rewrite for webView module. It’s way falling behind in terms of its quality & features. See this feature request:
And I am recently confronting another problem when handling webView orientation change. I am not sure if it’s my mistake or something wrong again in webView. I am working on this currently.
Voted on your request (although I firmly believe CL pays no attention to them…). Thanks for sharing your findings.
To be clear, I was experiencing the issue on-device, in build >2100 but the workaround worked in 2100 (which we’re building against currently). I was never able to crash the simulator, but was able to crash the app on both a 4th gen iPod touch running iOS 6.x and iPhone 5 on iOS 7.0.4.
I only have an iPhone 5 and an iPad 3.