[TIMOB-2641] WebView.reload() breaks fireEvent/listener connection
GitHub Issue | n/a |
---|---|
Type | Bug |
Priority | Trivial |
Status | Closed |
Resolution | Fixed |
Resolution Date | 2011-05-11T14:54:50.000+0000 |
Affected Version/s | n/a |
Fix Version/s | Release 1.7.0, Sprint 2011-16 |
Components | iOS |
Labels | fireevent, ios, klist, webview |
Reporter | Jérémy R |
Assignee | Blain Hamon |
Created | 2011-04-15T03:25:36.000+0000 |
Updated | 2011-05-11T14:54:50.000+0000 |
Description
I encounter some weird behavior and found there was a previous issue concerning http://developer.appcelerator.com/question/58681/android-tiappfireevent-looses-connection-to-event-listener" title="WebView.url(newUrl)">WebView.url(newUrl).
When I call WebView.reload() after a screen rotation (else the WebView doesn't resize it's content) then the connection is broken.
More info about what happens:
function openDocument(docURL) {
alert('webview click received // ' + docURL);
Ti.App.fireEvent('customOpenDocument', {url:docURL});
alert('webview click received CALL ENDED');
};</code>
The first alert shows up. But I never receive the fired event, and the 2nd alert doesn't show up. However I no reload() was previously called, then the event is received and the 2nd alert show.
SDK 1.5.1 / iPad
Attachments
File | Date | Size |
---|---|---|
archive.zip | 2011-04-15T03:25:36.000+0000 | 1203 |
fireEvent is lost after webview.reload(); is called. Event fires once and and as soon as webview is reloaded event is los
Ticket Reference and testing code: http://developer.appcelerator.com/helpdesk/view/72421">http://developer.appcelerator.com/helpdesk/view/72421
Simple Testing Code attached.
I'm confused here. You're calling reload(), which loads the page up as if it were completely fresh and new (Akin to hitting reload on a web browser). By definition, the state of the web view will be lost because it's reloading.
The fact is that the listener doesn't (in application) does not receive an event which is fired from a webview that have been reload.
It has to re-register itself as a listener.
Let's investigate this further. There appears to be a workaround, but perhaps we could do more for our customer.
Reggie: what is the workaround exactly?
The workaround was simply setting the url or html again. The native web view reload wasn't giving us time to do the injection. It's fixed now.
No longer able to reproduce with iPhone 4, iOS 4.3.3. KS 1.7.0, build 1.7.0.879871b. Closing