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

[darin]

The following commit has been merged in the debian/unstable branch:
commit 95c9516ba711c9010dd969e49ce29546bedc2d08
Author: darin <darin at 268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Date:   Tue Dec 23 23:52:44 2003 +0000

    Fix some old malformed log entries.
    
    
    git-svn-id: http://svn.webkit.org/repository/webkit/trunk@5849 268f45cc-cd09-0410-ab3c-d52691b4dbfc

diff --git a/WebKit/ChangeLog b/WebKit/ChangeLog
index 0e6ee11..b18cfe4 100644
--- a/WebKit/ChangeLog
+++ b/WebKit/ChangeLog
@@ -59,7 +59,8 @@
 
 2003-12-17  Richard Williamson   <rjw at apple.com>
 
-	Fixed 3503011 (really, this time).  Always use integer width for '-' and '?', as we do for spaces, to ensure that 'words' (as defined by out rounding hack) start on integer boundaries.
+	Fixed 3503011 (really, this time).  Always use integer width for '-' and '?', as we do for spaces, to ensure
+        that 'words' (as defined by out rounding hack) start on integer boundaries.
 
         Reviewed by John.
 
@@ -14067,14 +14068,9 @@ l.
 
 	Fixed: 3160464 - Slideback sometimes happens twice
 
-	Because we start drags in mouseDragged (which AppKit says we shouldn't), we get mouseDragged events after a drag (image, link, text etc) has ended. We also get mouseDragged events after we've sent the fake mouseUp to WebCore. That is probably bad for unk
-
-
-
-
-
-
-nown reasons.
+	Because we start drags in mouseDragged (which AppKit says we shouldn't), we get mouseDragged events
+        after a drag (image, link, text etc) has ended. We also get mouseDragged events after we've sent the
+        fake mouseUp to WebCore. That is probably bad for unknown reasons.
 
         Reviewed by darin.
 
@@ -14566,20 +14562,18 @@ nown reasons.
 
 2003-01-22  Chris Blumenberg  <cblu at apple.com>
 
-	Fixed problem where we weren't stopping the Java plug-in. This problem was introduced on Jan. 1 when the ownership of the WebPluginController was moved from WebFrame to WebDataSource. This change moves the WebPluginController to the WebHTMLView. Why this
-
-
-
-
-
-
- change?
+	Fixed problem where we weren't stopping the Java plug-in. This problem was introduced on Jan. 1
+        when the ownership of the WebPluginController was moved from WebFrame to WebDataSource. This
+        change moves the WebPluginController to the WebHTMLView. Why this 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.
+	- 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.
 
-	- WebHTMLView and WebDataSource are usually coupled via WebView and WebFrame, but not always. In a transitional state, the WebHTMLView may not be up to date with the WebDataSource.
+	- WebHTMLView and WebDataSource are usually coupled via WebView and WebFrame, but not always.
+          In a transitional state, the WebHTMLView may not be up to date with the WebDataSource.
 
-	- WebPluginController controls an array of views. It makes more sense for this object to be owned by a view (WebHTMLView) not a model.
+	- WebPluginController controls an array of views. It makes more sense for this object to be
+          owned by a view (WebHTMLView) not a model.
 
         Reviewed by darin.
 

-- 
WebKit Debian packaging