a crash when exiting an overlay scene with a webView (only happens in iOS device testing)

ksan · February 5, 2014, 2:25am

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

rob · February 5, 2014, 2:36am

That bug has been filed.

Rob

ksan · February 5, 2014, 3:22am

Love it when you say that! :)

Thank you very much!

max84 · February 5, 2014, 3:47pm

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.

joe528 · February 6, 2014, 3:56am

rob:

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).

This is a very common request, not only with webView’s but any thing that is of the native.* API family. Corona SDK is built upon OpenGL. All of our drawing tools, like the display.* API’s, graphics.* API’s and such render to the Open GL canvas. To the actual app, they get a screen buffer that’s updated either 30 or 60 times per second. Native objects, as defined by the various operating systems do not interact with the OpenGL canvas. For iOS, Android and OS-X they sit on a layer above the OpenGL canvas. For Windows, the native.* objects have to be in a separate window completely. There is nothing that Corona Labs or any other software using the OpenGL graphics can do about this. We wish it were possible, but it’s not. It is also not practical to try and build an OpenGL version of these very complex features.

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

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.

boscotwcheung · February 6, 2014, 7:55am

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.

rob · February 7, 2014, 12:20am

@boscotwcheung, This has not been fixed yet.

joe528 · February 12, 2014, 5:49am

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.

boscotwcheung · February 12, 2014, 7:05am

It works for me using daily build 2174

boscotwcheung · February 12, 2014, 7:06am

No crashes using Daily Build 2174, yeah and thanks!

AlanPlantPot · April 3, 2014, 4:02pm

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&nbsp;

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&nbsp;

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?

AlanPlantPot · April 23, 2014, 9:55am

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.

rob · April 23, 2014, 11:19pm

Can you produce a small app that demos the problem still? This is the first set of complaints about this in a while.

AlanPlantPot · April 3, 2014, 4:02pm

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&nbsp;

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&nbsp;

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?

AlanPlantPot · April 23, 2014, 9:55am

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.

rob · April 23, 2014, 11:19pm

Can you produce a small app that demos the problem still? This is the first set of complaints about this in a while.

Alan_PlantPot · September 17, 2014, 2:16pm

We’re still seeing this same issue where a removed webview causes segmentation fault crashes.

In my case, our game supports all orientations. We have a pull down menu which contains a webview, and when the game rotates we remove this menu+webview and redraw them as a different size to better fit the screen.

If the webview has not finished loading, it almost always causes a crash (it’s hard to tell how often because the webview is sometimes off screen).

It seems that:

webView:stop() webView:removeEventListener( "urlRequest", webListener )

have no effect if a request is still incoming.

We’ve just had to retract a submission to apple because we spotted this after submitting, and we’re trying to come up with a suitable workaround. So while I would like to make a sample app, I’m not sure I can right now.

I’m using daily build 2014.2432, which is only a few days old.

rob · September 18, 2014, 12:16am

Can you file a bug report? We think this was fixed, and if its not working, Engineering will need something to go on.

Rob

Alan_PlantPot · September 17, 2014, 2:16pm