Reviewed by Kevin Decker.
authortomernic <tomernic@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Tue, 7 Mar 2006 02:05:57 +0000 (02:05 +0000)
committertomernic <tomernic@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Tue, 7 Mar 2006 02:05:57 +0000 (02:05 +0000)
commit99c58cbdb40c403018c1f6056c17424f0680d6d1
tree5ac9e17523237d3faf0277cbfb226cf90f7f1830
parent3297693e55c4a27da8b0ea8587950e0ad0b040c5
    Reviewed by Kevin Decker.

        <rdar://problem/4457574> assertion failure watching trailers at netflix.com -[WebNetscapePluginRepresentation
        receivedData:withDataSource:] + 684

        * Plugins/WebNetscapePluginRepresentation.m:
        (-[WebNetscapePluginRepresentation receivedData:withDataSource:]):
        Moved the ASSERT(instance) to the block that actually requires an assertion -- the plugin view should never
        have a NULL instance by the time we start the NPStream (by calling -startStreamWithResponse:).
        Some stream teardown logic changed with my fix to 4153419: when a WebBaseNetscapePluginStream is destroyed,
        it now clears its NPP instance backpointer.  The WebBaseNetscapePluginStream may be destroyed from within
        -startStreamWithResponse: if NPP_NewStream() returns an error.  We can handle this gracefully by changing
        the assertion before -receivedData: to a simple NULL check.
        This is unrelated to the Radar, but prior to this fix, we would attempt an NPP_Write() with the initial
        stream data even if NPP_NewStream() returned an error.  Seems like that alone could cause issues, though
        I'm guessing that plugins handle this in practice.

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@13183 268f45cc-cd09-0410-ab3c-d52691b4dbfc
WebKit/ChangeLog
WebKit/Plugins/WebNetscapePluginRepresentation.m