[Webkit-unassigned] [Bug 138443] Crash in NSURLConnectionInternal, messaging released WebView

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=138443

--- Comment #19 from Daniel Jalkut <jalkut at red-sweater.com> ---
Interesting point, Darin. I guess this is probably a "lesser of two evils" situation, and the "anything could happen" complexity (from my perspective) of the tear down makes me worry that weird edge cases exist where the WebView could get autoreleased.

Although it certainly seems odd and unexpected to retain an object during release, I have to imagine it's pretty innocuous, considering the object is literally on the verge of being eliminated. So long as dealloc doesn't concern itself with the retain count of an object, I think it would be safe to retain it a million times before the end of dealloc, even if it would feel gross.

Alexey, for the sake of brainstorming on the two cases you list:

1. The retain/release pair for the notification posting seem especially innocuous since the post call is synchronous and the retain will be followed very shortly by a release.

2. What kind of commitment does WebView have to the web content's JavaScript unload handlers? It seems reasonable to me that such unload handlers should be prepare to face a scenario where e.g. a network request just doesn't work, or instantly times out. After all, the web content is one the way down the drain, right? Are there other obvious JavaScript tasks that would result in the WebView being retained? I wonder if the tear down process can be orchestrated such that before the JavaScript unload handlers are called, the WebView is in such a state that it will not follow code paths that result in further retaining or autoreleasing itself?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20141107/9d119a56/attachment-0002.html>