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

index 1a85af8cfd727327ae6db43afa76662f481a2ee8..461a36876858b0adb79b36c057442ecdfe42d8a9 100644 (file)
@@ -1,3 +1,22 @@
+2006-03-06  Tim Omernick  <timo@apple.com>
+
+        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.
+
 2006-03-03  Timothy Hatcher  <timothy@apple.com>
 
         Reviewed by Darin.
index 6c8329b406a71a6622056c688c026e27bfd0b2ca..b95c115386280cfc3bf56f483340d929500d0218 100644 (file)
     if (instance == NULL) {
         [self setRequestURL:[[_dataSource request] URL]];
         [self setPluginPointer:[view pluginPointer]];
+        ASSERT(instance);
         [self startStreamWithResponse:[ds response]];
     }
     
-    ASSERT(instance != NULL);
-    [self receivedData:data];
+    // Do not add data if there is no NPP instance.  The instance is cleared when the stream is destroyed.
+    if (instance)
+        [self receivedData:data];
 }
 
 - (void)receivedError:(NSError *)error withDataSource:(WebDataSource *)ds