Commit 262baf71 authored by bdakin's avatar bdakin
Browse files

WebCore:

        Rendering part reviewed by Hyatt. Editing part consulted with and 
        rubber stamped by Justin and Harrison.

        Fix for <rdar://problem/5025925> A hang occurs in Safari when 
        attempting to print page at http://www.pcadvisor.co.uk

        * rendering/RenderBlock.cpp:
        (WebCore::RenderBlock::makeChildrenNonInline): 
        RenderBlock::makeChildrenNonInline() takes a block's inline 
        children and turns them into block children. If the children had 
        line boxes, those boxes were being leaked. In the layout test I 
        added with the change (and at pcadvisor.co.uk during printing) 
        children were being made non-inline, and then they were being made 
        inline again. This meant that some of the children ended up 
        pointing to totally stale line boxes that are normally just leaked. 
        This caused an infinite loop in RenderFlow::destroy(). This patch 
        simply deletes everyone's line boxes in 
        RenderBlock::makeChildrenNonInline()

        * editing/InsertParagraphSeparatorCommand.cpp:
        (WebCore::InsertParagraphSeparatorCommand::doApply): The other part 
        of this fix is that I added a call to updateLayout in 
        InsertParagraphSeparatorCommand::doApply(). One layout test 
        (editing/spelling/spelling.html) was changed by my patch to 
        RenderBlock. doApply() inserts a node into the render tree. In at 
        least one case in spelling.html, that caused some line boxes to be 
        deleted. Back in doApply() this meant that the RenderTree was out-
        of-date, and we mistakenly thought we were at the end of the 
        paragraph. This caused us to insert a RenderBR() at the end of the 
        tree instead of an empty RenderText(). No one seems to know exactly 
        why we insert either, or if the change is necessarily a problem. It 
        is clear, though, that the RenderTree in doApply() is out-of-date 
        after inserting the node and deleting some line boxes, so it seems 
        prudent to call into updateLayout().

LayoutTests:
        Reviewed by Hyatt.

        Test for <rdar://problem/5025925> A hang occurs in Safari when 
        attempting to print page at http://www.pcadvisor.co.uk

        * fast/block/float/nestedAnonymousBlocks-expected.checksum: Added.
        * fast/block/float/nestedAnonymousBlocks-expected.png: Added.
        * fast/block/float/nestedAnonymousBlocks-expected.txt: Added.
        * fast/block/float/nestedAnonymousBlocks.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@20177 268f45cc-cd09-0410-ab3c-d52691b4dbfc
parent 5b8f351d
2007-03-13 Beth Dakin <bdakin@apple.com>
Reviewed by Hyatt.
Test for <rdar://problem/5025925> A hang occurs in Safari when
attempting to print page at http://www.pcadvisor.co.uk
* fast/block/float/nestedAnonymousBlocks-expected.checksum: Added.
* fast/block/float/nestedAnonymousBlocks-expected.png: Added.
* fast/block/float/nestedAnonymousBlocks-expected.txt: Added.
* fast/block/float/nestedAnonymousBlocks.html: Added.
2007-03-13 David Harrison <harrison@apple.com>
<rdar://problem/5031181> cntl-k at end of paragraph adds nothing to the kill ring
83659cc9a5abab65a2d2531ce021d215
\ No newline at end of file
layer at (0,0) size 800x600
RenderView at (0,0) size 800x600
layer at (0,0) size 800x600
RenderBlock {HTML} at (0,0) size 800x600
RenderBody {BODY} at (8,8) size 784x584
RenderBlock (floating) {DIV} at (0,0) size 201x18
RenderBlock {DIV} at (0,0) size 201x18
RenderText {#text} at (0,0) size 201x18
text run at (0,0) width 201: "This is a test for rdar://5025925."
RenderBlock (floating) {DIV} at (201,0) size 299x18
RenderBlock {DIV} at (0,0) size 299x18
RenderText {#text} at (0,0) size 299x18
text run at (0,0) width 299: "The test succeeds if this does not hang or crash."
RenderBlock (anonymous) at (0,0) size 784x18
RenderText {#text} at (500,0) size 4x18
text run at (500,0) width 4: " "
RenderBlock {DIV} at (0,18) size 784x0
<html>
<head>
<style type="text/css" media="Screen">
#leftColumn, #centreColumn {
float: left;
}
</style>
</head>
<body>
<div id="leftColumn">
<div>This is a test for rdar://5025925.</div>
</div>
<div id="centreColumn">
<div> The test succeeds if this does not hang or crash.</div>
</div>
&nbsp;
<div></div>
<script>
var lefty = document.getElementById("leftColumn");
var center = document.getElementById("centreColumn");
lefty.offsetWidth;
lefty.style.display = "none";
lefty.style.float = "none";
center.style.float = "none";
center.offsetWidth;
lefty.style.display = "block";
lefty.style.float = "left";
center.style.float = "left";
</script>
</body>
</html>
2007-03-13 Beth Dakin <bdakin@apple.com>
Rendering part reviewed by Hyatt. Editing part consulted with and
rubber stamped by Justin and Harrison.
Fix for <rdar://problem/5025925> A hang occurs in Safari when
attempting to print page at http://www.pcadvisor.co.uk
* rendering/RenderBlock.cpp:
(WebCore::RenderBlock::makeChildrenNonInline):
RenderBlock::makeChildrenNonInline() takes a block's inline
children and turns them into block children. If the children had
line boxes, those boxes were being leaked. In the layout test I
added with the change (and at pcadvisor.co.uk during printing)
children were being made non-inline, and then they were being made
inline again. This meant that some of the children ended up
pointing to totally stale line boxes that are normally just leaked.
This caused an infinite loop in RenderFlow::destroy(). This patch
simply deletes everyone's line boxes in
RenderBlock::makeChildrenNonInline()
* editing/InsertParagraphSeparatorCommand.cpp:
(WebCore::InsertParagraphSeparatorCommand::doApply): The other part
of this fix is that I added a call to updateLayout in
InsertParagraphSeparatorCommand::doApply(). One layout test
(editing/spelling/spelling.html) was changed by my patch to
RenderBlock. doApply() inserts a node into the render tree. In at
least one case in spelling.html, that caused some line boxes to be
deleted. Back in doApply() this meant that the RenderTree was out-
of-date, and we mistakenly thought we were at the end of the
paragraph. This caused us to insert a RenderBR() at the end of the
tree instead of an empty RenderText(). No one seems to know exactly
why we insert either, or if the change is necessarily a problem. It
is clear, though, that the RenderTree in doApply() is out-of-date
after inserting the node and deleting some line boxes, so it seems
prudent to call into updateLayout().
2007-03-13 Adam Roben <aroben@apple.com>
 
Reviewed by Anders.
......
......@@ -11229,7 +11229,6 @@
0867D690FE84028FC02AAC07 /* Project object */ = {
isa = PBXProject;
buildConfigurationList = 149C284308902B11008A9EFC /* Build configuration list for PBXProject "WebCore" */;
compatibilityVersion = "Xcode 2.4";
hasScannedForEncodings = 1;
knownRegions = (
English,
......@@ -11244,7 +11243,6 @@
productRefGroup = 034768DFFF38A50411DB9C8B /* Products */;
projectDirPath = "";
projectRoot = "";
shouldCheckCompatibility = 1;
targets = (
93F198A508245E59001E9ABC /* WebCore */,
DD041FBE09D9DDBE0010AF2A /* Derived Sources */,
......@@ -234,6 +234,8 @@ void InsertParagraphSeparatorCommand::doApply()
else
insertNodeAfter(blockToInsert.get(), startBlock);
updateLayout();
// Make clones of ancestors in between the start node and the start block.
RefPtr<Node> parent = blockToInsert;
for (size_t i = ancestors.size(); i != 0; --i) {
......
......@@ -283,6 +283,15 @@ void RenderBlock::makeChildrenNonInline(RenderObject *insertionPoint)
m_childrenInline = false;
InlineFlowBox* line = m_firstLineBox;
InlineFlowBox* nextLine;
while (line) {
nextLine = line->nextFlowBox();
line->deleteLine(renderArena());
line = nextLine;
}
m_firstLineBox = m_lastLineBox = 0;
RenderObject *child = firstChild();
while (child) {
......
......@@ -1280,7 +1280,6 @@
0867D690FE84028FC02AAC07 /* Project object */ = {
isa = PBXProject;
buildConfigurationList = 149C283208902B0F008A9EFC /* Build configuration list for PBXProject "WebKit" */;
compatibilityVersion = "Xcode 2.4";
hasScannedForEncodings = 1;
knownRegions = (
English,
......@@ -1295,7 +1294,6 @@
productRefGroup = 034768DFFF38A50411DB9C8B /* Products */;
projectDirPath = "";
projectRoot = "";
shouldCheckCompatibility = 1;
targets = (
9398100A0824BF01008DF038 /* WebKit */,
);
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment