[SCM] WebKit Debian packaging branch, debian/unstable, updated. debian/1.1.15-1-40151-g37bb677

[cblu]

The following commit has been merged in the debian/unstable branch:
commit 56ea1e7ed8a4df6cb43a4a805e2d967df7fc6c12
Author: cblu <cblu at 268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Date:   Fri Jun 13 19:03:51 2003 +0000

    	Fixed previous " Reviewed by" string.
    
            * ChangeLog:
    
    
    git-svn-id: http://svn.webkit.org/repository/webkit/trunk@4543 268f45cc-cd09-0410-ab3c-d52691b4dbfc

diff --git a/WebKit/ChangeLog b/WebKit/ChangeLog
index b99e1c7..397518f 100644
--- a/WebKit/ChangeLog
+++ b/WebKit/ChangeLog
@@ -1,8 +1,14 @@
 2003-06-13  Chris Blumenberg  <cblu at apple.com>
 
+	Fixed previous " Reviewed by" string.
+
+        * ChangeLog:
+
+2003-06-13  Chris Blumenberg  <cblu at apple.com>
+
 	Fixed: <rdar://problem/3291502>: REGRESSION (80-81): freebsd.org is giving us gzipped content (because we stopped spoofing)
 
-        Reviewed by darin.
+        Reviewed by john.
 
         * WebView.subproj/WebUserAgentSpoofTable.c:
         (hash):
@@ -138,7 +144,9 @@
         (-[WebFrame _setPolicyDataSource:]): new
         (-[WebFrame _checkNavigationPolicyForRequest:dataSource:formState:andCall:withSelector:]): don't call _prepareForProvisionalLoadWithDataSource::, don't muck with policyDataSource because it is only needed in the regular load case
         (-[WebFrame _continueAfterNavigationPolicy:]): don't call _prepareForProvisionalLoadWithDataSource::, call _setPolicyDataSource:nil after _continueLoadRequestAfterNavigationPolicy:: has used policyDataSource
-        (-[WebFrame _continueLoadRequestAfterNavigationPolicy:formState:]): this method covers the regular load case. This is where we need to stop the load, set the load type and the provisional data source. Code was in _prepareForProvisionalLoadWithDataSource::
+        (-[WebFrame _continueLoadRequestAfterNavigationPolicy:formState:]): this method covers the regular load case. This is where we need to stop the load, set the load type and the provisional data source. Code was in _prepareForProvisionalLoadWithData
+
+Source::
         (-[WebFrame _loadDataSource:withLoadType:formState:]): set the policyLoadType and policyDataSource (the beginning of the regular load case)
 
 2003-06-10  Richard Williamson   <rjw at apple.com>
@@ -167,7 +175,9 @@
         (-[WebFrame _continueFragmentScrollAfterNavigationPolicy:formState:]): formatting tweak
         (-[WebFrame _loadURL:referrer:loadType:target:triggeringEvent:form:formValues:]): formatting tweak
         (-[WebFrame _continueLoadRequestAfterNavigationPolicy:formState:]): if there is no request to continue with, don't reset things like the provisional data source since it was never unset in this case
-        (-[WebFrame _loadDataSource:withLoadType:formState:]): don't call stopLoading, _setLoadType and _setProvisionalDataSource, since that stops the frame even for command-click and option-click. Do this work in _prepareForProvisionalLoadWithDataSource:loadType: instead.
+        (-[WebFrame _loadDataSource:withLoadType:formState:]): don't call stopLoading, _setLoadType and _setProvisionalDataSource, since that stops the frame even for command-click and option-click. Do this work in _prepareForProvisionalLoadWithDataSource
+
+:loadType: instead.
 
 2003-06-10  Richard Williamson   <rjw at apple.com>
 
@@ -434,7 +444,11 @@
 
 
 	Eric Carlson:
-	The problem happens when you call NPP_SetWindow with a 0 width or height more than once. The first call to NPP_SetWindow always seems to have width and height set to 0, but the next call sometimes has it set to the correct values (those in the EMBED tag). This is when it draws successfully. It seems to me that the fix is to always pass the correct width and height to NPP_SetWindow. You always position the plug-in far offscreen (1000000, -52) and set the clip region to an empty rect (48576, 52, 48576, 52) so there isn't really any danger of the plug-in drawing anyway. Additionally, you pass the correct width and height in the call to NPP_New before the first call to NPP_SetWindow.
+	The problem happens when you call NPP_SetWindow with a 0 width or height more than once. The first call to NPP_SetWindow always seems to have width and height set to 0, but the next call sometimes has it set to the correct values (those in the EMBED tag)
+
+. This is when it draws successfully. It seems to me that the fix is to always pass the correct width and height to NPP_SetWindow. You always position the plug-in far offscreen (1000000, -52) and set the clip region to an empty rect (48576, 52, 48576, 52)
+
+ so there isn't really any danger of the plug-in drawing anyway. Additionally, you pass the correct width and height in the call to NPP_New before the first call to NPP_SetWindow.
 
         Reviewed by john, darin.
 
@@ -6386,6 +6400,8 @@
 
 	Instead of creating and managing resourceData in WebMainResourceClient then passing the ownership to WebDataSource, just manage it in WebDataSource. We had the prior behavior because we didn't buffer downloads. Now, we always buffer. The fix for the bug 
 
+
+
 is to retain the incomplete data even though the load ends in error.
 
         Reviewed by darin.
@@ -6448,6 +6464,8 @@ is to retain the incomplete data even though the load ends in error.
 
 	We start plug-ins when they are added to the window and stop them when they are removed. To restart a plug-in, the data stream must be redelivered. This works in the embedded plug-in case, but in the standalone plug-in case, the stream is delivered by th
 
+
+
 e machinery in WebKit. The stream is only delivered once. This fix addresses that.
 
         Reviewed by trey.
@@ -6913,6 +6931,8 @@ e machinery in WebKit. The stream is only delivered once. This fix addresses tha
         (-[WebDownloadPrivate dealloc]): release the WebResourceDelegateProxy
         (-[WebDownload _initWithLoadingResource:request:response:delegate:proxy:]): renamed, don't pass a datasource so WebDownload is completely disconnected from the that. Pass the proxy so it transfers ownership from WebMainResourceClient and it doesn'
 
+
+
 t leak when we cancel a download.
         (-[WebDownload _setRequest:]): added
         (-[WebDownload _setResponse:]): added
@@ -7050,6 +7070,8 @@ t leak when we cancel a download.
 
         * Downloads.subproj/WebDownload.h: Changed the download delegate method from download:didStartFromDataSource: download:didStartFromRequest:. Passing the data source wasn't that helpful. It was also quirky that the data source would sometimes be ni
 
+
+
 l.
         * Downloads.subproj/WebDownload.m:
         (-[WebDownloadPrivate dealloc]): release directory path
@@ -9044,6 +9066,8 @@ l.
 
 
 
+
+
 nown reasons.
 
         Reviewed by darin.
@@ -9541,6 +9565,8 @@ nown reasons.
 
 
 
+
+
  change?
 
 	- The state of the plug-ins (currently only the Java plug-in) completely relies on the state of the WebHTMLView, not on the state of the WebDataSource.
@@ -10860,6 +10886,8 @@ nown reasons.
 
 
 
+
+
 ts each with 60 timeouts. The event also cause the Finder to do a lot of work.
 
 	We should:
@@ -10880,6 +10908,8 @@ ts each with 60 timeouts. The event also cause the Finder to do a lot of work.
 
 
 
+
+
 nds 2 apple events both with a 60 second timeout. This method returns immediately.
         * WebKit.pbproj/project.pbxproj:
 
@@ -11511,6 +11541,8 @@ nds 2 apple events both with a 60 second timeout. This method returns immediatel
 
 
 
+
+
 en't providing the declared data. 
 
         * Misc.subproj/WebNSPasteboardExtras.h:

-- 
WebKit Debian packaging