native.newWebView's URLRequest event.type 'loaded' not behaving on iOS devices

Sure, we are all waiting!

Yes, our client is also in need of this fix for a fast-approaching launch of their app. Please fix soon

+1 this “loaded” event is very important to implement two features:

(1) to get the current URL link that the user is browsing

(2) to show a loading indicator while the web page is loading (webView only shows the loading indicator in iOS for the first time-loading, no more loading indication afterwards, so I have to show it by myself, otherwise the user don’t know if the webView is actually trying hard to load. It’s a bad user experience when there is no loading indicator)

I think there are many improvement areas for this webView. I really hope Corona can enhance it here and there, otherwise it’s really bad for making a business app that uses webView heavily.

I am having the same problem too. 

This is a stopping bug for me, as I have integrated native.newWebView as a light weight browser into version 1.1 of ICE: Internet Concept Explorer.  Without this fixed, I can’t have a loading indicator, which is bad, but not fatal.  Even worse is that I can’t tell where the user has browsed… making their option to opt-out to Safari impossible.

In the release note of build 2089, it says

  • iOS: Updating WebView to generate loaded events for back/forward/reload/link

I have tested it but I think there are three problems:

(1) There is only one loaded event. It behaves different than Android or the simulator. (I can live with this problem but the next two problems need to be addressed)

(2) The loaded event is generated very fast before the page is shown in the webView. If I display a loading indicator, it will disappear before the user sees the page that is being loaded. 

(3) In some cases, a loaded event is still missing. If you go to a page before it’s fully loaded and then click a link inside of it, the webView listener generates some -999 errors,

The operation couldn’t be completed. (NSURLErrorDomain error -999.)

This error can be safely ignored, and the webView actually loads a new page, however there is no loaded event for this case. 

Is this a final fix or there is more to come?

Hey Joe528:

I tested this fix Tuesday, at the request of Corona engineering staff.  I found a number of issues too… a mostly different set from yours, although I did also find your first observation, namely, that the Mac Simulator operates differently from my iPad device.  I like the way the iPad works better, so that’s good, if not perfect.

On my testing iPad 2, running iOS 7, on build 2090, I did not observe #2… it looked to me that the ‘loaded’ message coincided with the first appearance of the page… but I did see that the page was not always fully loaded.  I find this acceptable, as I am interested in letting the user know that ‘somethings happening’ when I shut down the loading indicator, and the page starting to fill is OK with me towards that end.

#3 looks fatal to me, as my loading indicator will spin forever.  :(  I did not notice this in my testing, although I found something similar with event.type ‘form’ pages… a loading message may or may not be issued for the original form url, and is never issued for any follow-on button presses at the site.  I can live (but don’t like) with never getting a message for the follow on pages, but the flaky first message is a tough one.

When I notified Corona of the results of my testing, I got the impression that ‘it is what it is’.  I wanted to take the Holiday to think about how far down the road this latest fix gets me, and whether I can work with it…

David

Hi cosmic

Thanks for the reply.

Yes, for #1, it’s actually ok.

For #2, the first page is ok, just like what you said, although it’s not fully loaded, at least some part of the page is shown. However, what I really meant, if you click some link after the first page, don’t you get the loaded event before the 2nd page appears on the webView? Except the first page, from my observation, the “only” loaded event comes too early for all subsequent pages.

#3, yes, very fatal, not only your loading indicator will not stop, but also you don’t know the current URL has changed. Besides, this case is a very basic scenario and happens now and then.

I think #3 is definitely a bug, they can’t just consider it is what it is. :unsure: And there are more improvements to this webView and I really hope Corona can put more resources on it.

Hi Joe528,

I am back at it and I need to figure out what to do about these webview issues.  I did not notice the the early loading issue on subsequent pages, but there were definitely more things lurking around in there.

So my question now is this: do I blow off the webview as a feature in my app and push users off to Safari?  (This is very undesirable, as it confuses the novice user as to how to get back… which is clumsy on the iPad in any case.) 

Webview works ‘most of the time’… but is it better that the push off to Safari?  I’m sure my app (using wenview) will take some dings if items #2 and #3 can’t be resolved.  I wish I could figure out a clever work around.

Do you have a simple test app for this?  If so, we should send it to Corona with clear instructions for recreating the issues.  I was using my app as a testing ground, which has a LOT of other distractions.  If you don’t have a simple testing app, I will make one, send it to you, and we can make sure we have a clear set of instructions to reproduce the issues.  I believe the Corona staff will take a good look.

We have looked into the web view issue and believe that we’re correctly passing the message events through that iOS UIWebView provides.

A few items to note:

Web pages/servers can cause multiple loaded events depending on the content, frames, or whether there are redirects, which are passed through from iOS.

It’s important to look for error events in addition to the loaded events since web page loads are not guaranteed (i.e. unreachable hosts, or incomplete loads) We recommend having fallbacks in place to remove activity indicators after a reasonable timeout period has been reached in the event that the page never finishes loading.

The slight variations on OSX and Android are due to differences in implementation at the OS/control level and may differ for specific OS versions.

@cosmic

My app also uses webView heavily. So far, here are the improvements I am really hoping to see before I give up:

(1) Loading events to be more stable for iOS devices (what Bryan01 mentioned about page loads are not guaranteed, it’s understood, but for the problem #3, the new page actually loads but there is no loaded event!)

(2) Share to other apps (this has become quite a standard feature in many other apps when using an embedded webView)

(3) Copy text to the system clipboard (I want to copy the current URL to the clipboard so that the user can paste the URL in other apps, such as WhatsApp)

(4) Current webView is always on top because Corona claims it is the design. I am just wondering if it’s ever possible to make it like other display object so you can do more control with it. For example, when a user clicks some button, show up a panel on top of the webView for more operations. I see most apps with embedded web view has no limitations. Corona should also try it.

I have wrote (2) & (3) to the feature request page (for voting). (4) is probably a dream.

Unless you can connect with them directly, they will just tell you to write a feature request first. For the loading event, it’s possible for them to fix if they are persuaded that the loading event is actually missing instead of page loading problem.

This is still not fixed as of 2013.1260.  It works great on simulator and Android but on iOS device it only ever fires once as previously mentioned.

Please fix, as it’s been two months since the bug report was issued, and I really need this to update my app.

Thanks.

Sure, we are all waiting!

#3 on your list has been released as a beta plugin for ios. See the plugins page for more details

Thanks, Danny!

BTW, is there any way to gain access to the HTML code that comprised the current webview page?

David

Hi Brian,

Thanks for looking into this issue. Glad that you guys are correctly passing message events through the iOS UIWebview. Does this mean that you will soon (or have already) fixed the Corona iOS emulator? Last I looked they’re currently not matching in behaviors in regards to passing message events.

Regards

I have same problem  -_- 
Waiting for solution~ 

Yes, our client is also in need of this fix for a fast-approaching launch of their app. Please fix soon

+1 this “loaded” event is very important to implement two features:

(1) to get the current URL link that the user is browsing

(2) to show a loading indicator while the web page is loading (webView only shows the loading indicator in iOS for the first time-loading, no more loading indication afterwards, so I have to show it by myself, otherwise the user don’t know if the webView is actually trying hard to load. It’s a bad user experience when there is no loading indicator)

I think there are many improvement areas for this webView. I really hope Corona can enhance it here and there, otherwise it’s really bad for making a business app that uses webView heavily.

I am having the same problem too. 

This is a stopping bug for me, as I have integrated native.newWebView as a light weight browser into version 1.1 of ICE: Internet Concept Explorer.  Without this fixed, I can’t have a loading indicator, which is bad, but not fatal.  Even worse is that I can’t tell where the user has browsed… making their option to opt-out to Safari impossible.

In the release note of build 2089, it says

  • iOS: Updating WebView to generate loaded events for back/forward/reload/link

I have tested it but I think there are three problems:

(1) There is only one loaded event. It behaves different than Android or the simulator. (I can live with this problem but the next two problems need to be addressed)

(2) The loaded event is generated very fast before the page is shown in the webView. If I display a loading indicator, it will disappear before the user sees the page that is being loaded. 

(3) In some cases, a loaded event is still missing. If you go to a page before it’s fully loaded and then click a link inside of it, the webView listener generates some -999 errors,

The operation couldn’t be completed. (NSURLErrorDomain error -999.)

This error can be safely ignored, and the webView actually loads a new page, however there is no loaded event for this case. 

Is this a final fix or there is more to come?