RESOLVED FIXED Bug 52699
Allow Fixed Length values to be floating point
https://bugs.webkit.org/show_bug.cgi?id=52699
Summary Allow Fixed Length values to be floating point
Simon Fraser (smfr)
Reported 2011-01-18 21:48:26 PST
All Fixed Length values are currently truncated to ints. This is an issue for transforms, where the Length arguments to the various transform functions should really be floating point. Since we also interpolate through Lengths, this means that interpolated values are rounded to integers too.
Attachments
Extends the Length class so it can store floating point values. (13.55 KB, patch)
2011-02-08 20:06 PST, Rik Cabanier
simon.fraser: review-
Working patch with fixes for 2 layout tests (9.53 KB, text/plain)
2011-02-15 17:41 PST, Rik Cabanier
no flags
Working patch with fixes for 2 layout tests (9.53 KB, patch)
2011-02-15 17:43 PST, Rik Cabanier
no flags
new patch that fixes the style + removes setRawValue calls (12.53 KB, patch)
2011-02-18 15:51 PST, Rik Cabanier
no flags
split Length calculation in 2 seperate functions as not to disturb non-transform parameters (20.88 KB, patch)
2011-02-23 16:20 PST, Rik Cabanier
no flags
removed bit specifiers in Length structure (21.01 KB, patch)
2011-02-24 15:12 PST, Rik Cabanier
no flags
moved 'unsigned char' to 'bool' type (21.00 KB, patch)
2011-02-25 10:25 PST, Rik Cabanier
no flags
Updated patch with version that doesn't assert in debug mode (20.70 KB, patch)
2011-03-01 17:01 PST, Rik Cabanier
no flags
Updated patch with version that doesn't assert in debug mode + fixed style (20.70 KB, patch)
2011-03-03 11:05 PST, Rik Cabanier
no flags
Updated patch with version that doesn't assert in debug mode + fixed style (20.70 KB, text/plain)
2011-03-03 11:10 PST, Rik Cabanier
no flags
Updated patch with version that doesn't assert in debug mode + fixed style (20.80 KB, patch)
2011-03-03 11:15 PST, Rik Cabanier
no flags
latest fix for leopard (20.84 KB, patch)
2011-03-09 16:10 PST, Rik Cabanier
no flags
Rik Cabanier
Comment 1 2011-02-08 09:07:14 PST
*** Bug 53836 has been marked as a duplicate of this bug. ***
Rik Cabanier
Comment 2 2011-02-08 20:06:01 PST
Created attachment 81737 [details] Extends the Length class so it can store floating point values. The Length class now stores 8 bits for floating point and 16 for integer. This changes loses the range of values that this class takes and gives a limited range for floating. Another way of fixing this would be to add a union, but this would increase the memory footprint.
Simon Fraser (smfr)
Comment 3 2011-02-08 20:53:49 PST
Comment on attachment 81737 [details] Extends the Length class so it can store floating point values. View in context: https://bugs.webkit.org/attachment.cgi?id=81737&action=review > Source/WebCore/ChangeLog:7 > + No new tests. However, this fix can introduce differences in existing tests since it can make a small difference in layout In that case the patch needs to include new results for all the affected tests. This changelog entry needs to mention the changes in Length behavior. > Source/WebCore/platform/Length.h:33 > -const int percentScaleFactor = 128; > -const int intMaxForLength = 0x7ffffff; // max value for a 28-bit int > -const int intMinForLength = (-0x7ffffff - 1); // min value for a 28-bit int > +const int intMaxForLength = 0x7ffff; // max value for a 20-bit int > +const int intMinForLength = (-0x7ffff - 1); // min value for a 20-bit int I don't think it's acceptable to change the max and min int values that Length can store. That might break websites (which do things like z-index: 999999999).
Rik Cabanier
Comment 4 2011-02-09 00:10:07 PST
> > In that case the patch needs to include new results for all the affected tests. Will do so > > This changelog entry needs to mention the changes in Length behavior. > > > Source/WebCore/platform/Length.h:33 > > -const int percentScaleFactor = 128; > > -const int intMaxForLength = 0x7ffffff; // max value for a 28-bit int > > -const int intMinForLength = (-0x7ffffff - 1); // min value for a 28-bit int > > +const int intMaxForLength = 0x7ffff; // max value for a 20-bit int > > +const int intMinForLength = (-0x7ffff - 1); // min value for a 20-bit int > > I don't think it's acceptable to change the max and min int values that Length can store. That might break websites (which do things like z-index: 999999999). That doesn't work today either. Length can store at most 134217472 which is less than 999999999. The class also doesn't do bounds checking, so the larger value will overflow and become garbage. It seems that making it a full int or float is the correct solution. Is it acceptable that the class takes up 4 more bytes?
Simon Fraser (smfr)
Comment 5 2011-02-09 07:59:12 PST
(In reply to comment #4) > > > > In that case the patch needs to include new results for all the affected tests. > Will do so > > > > > This changelog entry needs to mention the changes in Length behavior. > > > > > Source/WebCore/platform/Length.h:33 > > > -const int percentScaleFactor = 128; > > > -const int intMaxForLength = 0x7ffffff; // max value for a 28-bit int > > > -const int intMinForLength = (-0x7ffffff - 1); // min value for a 28-bit int > > > +const int intMaxForLength = 0x7ffff; // max value for a 20-bit int > > > +const int intMinForLength = (-0x7ffff - 1); // min value for a 20-bit int > > > > I don't think it's acceptable to change the max and min int values that Length can store. That might break websites (which do things like z-index: 999999999). > > That doesn't work today either. Length can store at most 134217472 which is less than 999999999. The class also doesn't do bounds checking, so the larger value will overflow and become garbage. Bounds checking should happen elsewhere (e.g. in CSSPrimitiveValue methods). > It seems that making it a full int or float is the correct solution. Is it acceptable that the class takes up 4 more bytes? I don't know; we pass Lengths by value all over the place.
Rik Cabanier
Comment 6 2011-02-09 13:20:48 PST
999). > > > > That doesn't work today either. Length can store at most 134217472 which is less than 999999999. The class also doesn't do bounds checking, so the larger value will overflow and become garbage. > > Bounds checking should happen elsewhere (e.g. in CSSPrimitiveValue methods). > I'll check there too... > > It seems that making it a full int or float is the correct solution. Is it acceptable that the class takes up 4 more bytes? > > I don't know; we pass Lengths by value all over the place. I wasn't thinking of stack space. Is that a concern? It was more about heap space if a lot of length objects are stored. I've reimplemented my changes and the browser seems to render content fine, but I can't get a clean layout test. I reverted all my changes and tests are still failing. Do I need to do more than sync everything and get the fonts?
Rik Cabanier
Comment 7 2011-02-09 13:22:22 PST
My new implementation of length can store an int or float. It should behave the same for integer content.
Rik Cabanier
Comment 8 2011-02-09 21:43:18 PST
I think the falures are because I don't have the right fonts on my system. I'll try to get them installed or start developing on my mac.
Rik Cabanier
Comment 9 2011-02-15 17:41:27 PST
Created attachment 82556 [details] Working patch with fixes for 2 layout tests
Rik Cabanier
Comment 10 2011-02-15 17:42:17 PST
I have also have a test file that shows the fix but I'm unsure where it should go.
Rik Cabanier
Comment 11 2011-02-15 17:43:10 PST
Created attachment 82558 [details] Working patch with fixes for 2 layout tests
Dave Hyatt
Comment 12 2011-02-18 12:49:03 PST
I would just make the Length always be a float and not have it be both. Also the bitfield is completely useless now if you use the full 32 bits for the number (it's not saving you any space), so you can just turn those into bools. Lots of style errors too. You might want to flag for review just so you can see the style errors and fix them.
Rik Cabanier
Comment 13 2011-02-18 12:55:50 PST
(In reply to comment #12) > I would just make the Length always be a float and not have it be both. Also the bitfield is completely useless now if you use the full 32 bits for the number (it's not saving you any space), so you can just turn those into bools. > > Lots of style errors too. You might want to flag for review just so you can see the style errors and fix them. I was trying to minimize changes to the code. By having it behave differently only when the object is constructed with a float, we keep existing behavior. My first attempt was to move to just float, but it actually changes the result of a large number of operations. It resulted in a lot of changes all over the code and numerous problems and differences in the layout tests. Float also has less significant digits than int... The bitfield is actually still necessary because part of the table logic multiplies by 128. If the value was maxint, it results in overflows which cause incorrect layout. I will look at the style errors.
Dave Hyatt
Comment 14 2011-02-18 13:04:17 PST
You can just ditch rawValue also instead of keeping it. It has no meaning if the value isn't being hacked.
Dave Hyatt
Comment 15 2011-02-18 13:11:34 PST
I guess the union is fine for now. The engine's eventually going to move to floats, though, but if you want to keep ints in the underlying storage temporarily I suppose that's fine.
Rik Cabanier
Comment 16 2011-02-18 15:51:59 PST
Created attachment 83031 [details] new patch that fixes the style + removes setRawValue calls
Rik Cabanier
Comment 17 2011-02-18 15:53:03 PST
(In reply to comment #14) > You can just ditch rawValue also instead of keeping it. It has no meaning if the value isn't being hacked. I removed the setRawValue calls. However, I didn't remove the getRawValue because parts of the code use this to extract percentage values in fixed notation.
Rik Cabanier
Comment 18 2011-02-23 16:20:29 PST
Created attachment 83572 [details] split Length calculation in 2 seperate functions as not to disturb non-transform parameters
Rik Cabanier
Comment 19 2011-02-24 15:12:34 PST
Created attachment 83725 [details] removed bit specifiers in Length structure
Rik Cabanier
Comment 20 2011-02-25 10:25:14 PST
Created attachment 83831 [details] moved 'unsigned char' to 'bool' type
Dave Hyatt
Comment 21 2011-02-25 14:55:38 PST
Comment on attachment 83831 [details] moved 'unsigned char' to 'bool' type r=me
WebKit Commit Bot
Comment 22 2011-02-26 06:40:35 PST
Comment on attachment 83831 [details] moved 'unsigned char' to 'bool' type Clearing flags on attachment: 83831 Committed r79784: <http://trac.webkit.org/changeset/79784>
WebKit Commit Bot
Comment 23 2011-02-26 06:40:42 PST
All reviewed patches have been landed. Closing bug.
Pavel Feldman
Comment 24 2011-02-26 11:25:37 PST
Since recently, I am seeing assertion failure upon opening Web Inspector's network panel: (filed https://bugs.webkit.org/show_bug.cgi?id=55301 to track it). #0 0x1015d9687 in WebCore::Length::setValue at Length.h:91 #1 0x1019104ab in WebCore::FixedTableLayout::calcWidthArray at FixedTableLayout.cpp:121 #2 0x10191095f in WebCore::FixedTableLayout::computePreferredLogicalWidths at FixedTableLayout.cpp:204 #3 0x1020794d3 in WebCore::RenderTable::computePreferredLogicalWidths at RenderTable.cpp:574 #4 0x101f8c035 in WebCore::RenderBox::minPreferredLogicalWidth at RenderBox.cpp:659 #5 0x10207b2dc in WebCore::RenderTable::computeLogicalWidth at RenderTable.cpp:219 #6 0x10207a5f4 in WebCore::RenderTable::layout at RenderTable.cpp:278 #7 0x101f5ed92 in WebCore::RenderBlock::layoutBlockChild at RenderBlock.cpp:1958 #8 0x101f6093f in WebCore::RenderBlock::layoutBlockChildren at RenderBlock.cpp:1896 #9 0x101f60fb4 in WebCore::RenderBlock::layoutBlock at RenderBlock.cpp:1224 #10 0x101f5fc6e in WebCore::RenderBlock::layout at RenderBlock.cpp:1120 #11 0x101f83337 in WebCore::RenderObject::layoutIfNeeded at RenderObject.h:520 #12 0x101f5df34 in WebCore::RenderBlock::layoutPositionedObjects at RenderBlock.cpp:2137 #13 0x101f6128f in WebCore::RenderBlock::layoutBlock at RenderBlock.cpp:1255 #14 0x101f5fc6e in WebCore::RenderBlock::layout at RenderBlock.cpp:1120 #15 0x101f83337 in WebCore::RenderObject::layoutIfNeeded at RenderObject.h:520 #16 0x101f5df34 in WebCore::RenderBlock::layoutPositionedObjects at RenderBlock.cpp:2137 #17 0x101f6128f in WebCore::RenderBlock::layoutBlock at RenderBlock.cpp:1255 #18 0x101f5fc6e in WebCore::RenderBlock::layout at RenderBlock.cpp:1120 #19 0x101f83337 in WebCore::RenderObject::layoutIfNeeded at RenderObject.h:520 #20 0x101f5df34 in WebCore::RenderBlock::layoutPositionedObjects at RenderBlock.cpp:2137 #21 0x101f6128f in WebCore::RenderBlock::layoutBlock at RenderBlock.cpp:1255 #22 0x101f5fc6e in WebCore::RenderBlock::layout at RenderBlock.cpp:1120 #23 0x101f83337 in WebCore::RenderObject::layoutIfNeeded at RenderObject.h:520 #24 0x101f5df34 in WebCore::RenderBlock::layoutPositionedObjects at RenderBlock.cpp:2137 #25 0x101f6128f in WebCore::RenderBlock::layoutBlock at RenderBlock.cpp:1255 #26 0x101f5fc6e in WebCore::RenderBlock::layout at RenderBlock.cpp:1120 #27 0x101f83337 in WebCore::RenderObject::layoutIfNeeded at RenderObject.h:520 #28 0x101f5df34 in WebCore::RenderBlock::layoutPositionedObjects at RenderBlock.cpp:2137 #29 0x101f5fe50 in WebCore::RenderBlock::layoutOnlyPositionedObjects at RenderBlock.cpp:2087 #30 0x101f60a4e in WebCore::RenderBlock::layoutBlock at RenderBlock.cpp:1135 #31 0x101f5fc6e in WebCore::RenderBlock::layout at RenderBlock.cpp:1120 #32 0x101f83337 in WebCore::RenderObject::layoutIfNeeded at RenderObject.h:520 #33 0x101f5df34 in WebCore::RenderBlock::layoutPositionedObjects at RenderBlock.cpp:2137 #34 0x101f5fe50 in WebCore::RenderBlock::layoutOnlyPositionedObjects at RenderBlock.cpp:2087 #35 0x101f60a4e in WebCore::RenderBlock::layoutBlock at RenderBlock.cpp:1135 #36 0x101f5fc6e in WebCore::RenderBlock::layout at RenderBlock.cpp:1120 #37 0x101f83337 in WebCore::RenderObject::layoutIfNeeded at RenderObject.h:520 #38 0x101f5df34 in WebCore::RenderBlock::layoutPositionedObjects at RenderBlock.cpp:2137 #39 0x101f5fe50 in WebCore::RenderBlock::layoutOnlyPositionedObjects at RenderBlock.cpp:2087 #40 0x101f60a4e in WebCore::RenderBlock::layoutBlock at RenderBlock.cpp:1135 #41 0x101f5fc6e in WebCore::RenderBlock::layout at RenderBlock.cpp:1120 #42 0x1020b6fc3 in WebCore::RenderView::layout at RenderView.cpp:130 #43 0x101966cfc in WebCore::FrameView::layout at FrameView.cpp:906 #44 0x1017a5ef9 in WebCore::Document::updateLayout at Document.cpp:1592 #45 0x1017a85b8 in WebCore::Document::updateLayoutIgnorePendingStylesheets at Document.cpp:1623 #46 0x1018cd774 in WebCore::Element::focus at Element.cpp:1498 #47 0x101c3e412 in WebCore::jsElementPrototypeFunctionFocus at JSElement.cpp:1761 #48 0x279468c001b8 in ?? #49 0x1007e21f7 in JSC::JITCode::execute at JITCode.h:77 #50 0x1007dcc56 in JSC::Interpreter::executeCall at Interpreter.cpp:851 #51 0x10079632d in JSC::call at CallData.cpp:38 #52 0x100847b89 in JSC::JSObject::put at JSObject.cpp:149 #53 0x100815fbd in JSC::JSValue::put at JSObject.h:780 #54 0x10080f0ab in cti_op_put_by_id at JITStubs.cpp:1351 #55 0x100803dcd in WTF::doubleHash at HashTable.h:447 #56 0x1007e21f7 in JSC::JITCode::execute at JITCode.h:77 #57 0x1007dcc56 in JSC::Interpreter::executeCall at Interpreter.cpp:851 #58 0x10079632d in JSC::call at CallData.cpp:38 #59 0x100847b89 in JSC::JSObject::put at JSObject.cpp:149 #60 0x100815fbd in JSC::JSValue::put at JSObject.h:780 #61 0x10080f0ab in cti_op_put_by_id at JITStubs.cpp:1351 #62 0x100803dcd in WTF::doubleHash at HashTable.h:447 #63 0x1007e21f7 in JSC::JITCode::execute at JITCode.h:77 #64 0x1007dcc56 in JSC::Interpreter::executeCall at Interpreter.cpp:851 #65 0x10079632d in JSC::call at CallData.cpp:38 #66 0x1022d2f41 in WebCore::JSMainThreadExecState::call at JSMainThreadExecState.h:48 #67 0x101c50447 in WebCore::JSEventListener::handleEvent at JSEventListener.cpp:123 #68 0x1018ed642 in WebCore::EventTarget::fireEventListeners at EventTarget.cpp:354 #69 0x1018edc71 in WebCore::EventTarget::fireEventListeners at EventTarget.cpp:323 #70 0x101ec7d8f in WebCore::Node::handleLocalEvents at Node.cpp:2543 #71 0x1018d78d6 in WebCore::EventContext::handleLocalEvents at EventContext.cpp:48 #72 0x101ecff58 in WebCore::Node::dispatchGenericEvent at Node.cpp:2694 #73 0x101ed0379 in WebCore::Node::dispatchEvent at Node.cpp:2612 #74 0x101eceb58 in WebCore::Node::dispatchMouseEvent at Node.cpp:2902 #75 0x101ecf183 in WebCore::Node::dispatchMouseEvent at Node.cpp:2799 #76 0x1018df9af in WebCore::EventHandler::dispatchMouseEvent at EventHandler.cpp:1910 #77 0x1018e0f90 in WebCore::EventHandler::handleMouseReleaseEvent at EventHandler.cpp:1623 #78 0x1018e6fd5 in WebCore::EventHandler::mouseUp at EventHandlerMac.mm:546 #79 0x100ff8b3c in -[WebHTMLView mouseUp:] at WebHTMLView.mm:3764 #80 0x7fff8568d7ed in -[NSWindow sendEvent:] #81 0x100041bf5 in ?? #82 0x100041b81 in ?? #83 0x7fff855c2ee2 in -[NSApplication sendEvent:] #84 0x1000388c2 in ?? #85 0x7fff85559922 in -[NSApplication run] #86 0x7fff855525f8 in NSApplicationMain #87 0x100009b18 in ??
Alejandro G. Castro
Comment 25 2011-02-27 08:33:22 PST
This commit is causing a lot of crashes in the gtk debug bots: http://webkit-bots.igalia.com/amd64/svn_79817.core-when_1298824044-_-who_DumpRenderTree-_-why_11.trace.html Thread 1 (Thread 17474): #0 0x00007fde3407987e in WebCore::Length::setValue (this=0x1b54620, t=WebCore::Percent, value=2304) at ../../Source/WebCore/platform/Length.h:91 #1 0x00007fde3407e4fd in WebCore::FixedTableLayout::calcWidthArray (this=0x188c830) at ../../Source/WebCore/rendering/FixedTableLayout.cpp:121 #2 0x00007fde3407e9b7 in WebCore::FixedTableLayout::computePreferredLogicalWidths (this=0x188c830, minWidth=@0x1b3e578, maxWidth=@0x1b3e57c) at ../../Source/WebCore/rendering/FixedTableLayout.cpp:204 #3 0x00007fde3417b05e in WebCore::RenderTable::computePreferredLogicalWidths (this=0x1b3e518) at ../../Source/WebCore/rendering/RenderTable.cpp:574 #4 0x00007fde340ec421 in WebCore::RenderBox::minPreferredLogicalWidth (this=0x1b3e518) at ../../Source/WebCore/rendering/RenderBox.cpp:659 #5 0x00007fde34178e77 in WebCore::RenderTable::computeLogicalWidth (this=0x1b3e518) at ../../Source/WebCore/rendering/RenderTable.cpp:219 #6 0x00007fde3417951f in WebCore::RenderTable::layout (this=0x1b3e518) at ../../Source/WebCore/rendering/RenderTable.cpp:278 #7 0x00007fde340aaeea in WebCore::RenderBlock::layoutBlockChild (this=0x194a5a8, child=0x1b3e518, marginInfo=..., previousFloatLogicalBottom=@0x7fffbb9d376c, maxFloatLogicalBottom=@0x7fffbb9d38c4) at ../../Source/WebCore/rendering/RenderBlock.cpp:1961 #8 0x00007fde340aaaff in WebCore::RenderBlock::layoutBlockChildren (this=0x194a5a8, relayoutChildren=true, maxFloatLogicalBottom=@0x7fffbb9d38c4) at ../../Source/WebCore/rendering/RenderBlock.cpp:1899 #9 0x00007fde340a7a80 in WebCore::RenderBlock::layoutBlock (this=0x194a5a8, relayoutChildren=true, pageLogicalHeight=0) at ../../Source/WebCore/rendering/RenderBlock.cpp:1226 #10 0x00007fde340a7382 in WebCore::RenderBlock::layout (this=0x194a5a8) at ../../Source/WebCore/rendering/RenderBlock.cpp:1122 #11 0x00007fde340aaeea in WebCore::RenderBlock::layoutBlockChild (this=0x1b0b3a8, child=0x194a5a8, marginInfo=..., previousFloatLogicalBottom=@0x7fffbb9d3b7c, maxFloatLogicalBottom=@0x7fffbb9d3cd4) at ../../Source/WebCore/rendering/RenderBlock.cpp:1961 #12 0x00007fde340aaaff in WebCore::RenderBlock::layoutBlockChildren (this=0x1b0b3a8, relayoutChildren=false, maxFloatLogicalBottom=@0x7fffbb9d3cd4) at ../../Source/WebCore/rendering/RenderBlock.cpp:1899 #13 0x00007fde340a7a80 in WebCore::RenderBlock::layoutBlock (this=0x1b0b3a8, relayoutChildren=false, pageLogicalHeight=0) at ../../Source/WebCore/rendering/RenderBlock.cpp:1226 #14 0x00007fde340a7382 in WebCore::RenderBlock::layout (this=0x1b0b3a8) at ../../Source/WebCore/rendering/RenderBlock.cpp:1122 #15 0x00007fde340c001d in WebCore::RenderObject::layoutIfNeeded (this=0x1b0b3a8) at ../../Source/WebCore/rendering/RenderObject.h:520 #16 0x00007fde340abacc in WebCore::RenderBlock::layoutPositionedObjects (this=0x1801048, relayoutChildren=false) at ../../Source/WebCore/rendering/RenderBlock.cpp:2140 #17 0x00007fde340ab7a4 in WebCore::RenderBlock::layoutOnlyPositionedObjects (this=0x1801048) at ../../Source/WebCore/rendering/RenderBlock.cpp:2090 #18 0x00007fde340a74b1 in WebCore::RenderBlock::layoutBlock (this=0x1801048, relayoutChildren=false, pageLogicalHeight=0) at ../../Source/WebCore/rendering/RenderBlock.cpp:1137 #19 0x00007fde340a7382 in WebCore::RenderBlock::layout (this=0x1801048) at ../../Source/WebCore/rendering/RenderBlock.cpp:1122 #20 0x00007fde340c001d in WebCore::RenderObject::layoutIfNeeded (this=0x1801048) at ../../Source/WebCore/rendering/RenderObject.h:520 #21 0x00007fde340abacc in WebCore::RenderBlock::layoutPositionedObjects (this=0xc03988, relayoutChildren=false) at ../../Source/WebCore/rendering/RenderBlock.cpp:2140 #22 0x00007fde340ab7a4 in WebCore::RenderBlock::layoutOnlyPositionedObjects (this=0xc03988) at ../../Source/WebCore/rendering/RenderBlock.cpp:2090 #23 0x00007fde340a74b1 in WebCore::RenderBlock::layoutBlock (this=0xc03988, relayoutChildren=false, pageLogicalHeight=0) at ../../Source/WebCore/rendering/RenderBlock.cpp:1137 #24 0x00007fde340a7382 in WebCore::RenderBlock::layout (this=0xc03988) at ../../Source/WebCore/rendering/RenderBlock.cpp:1122 #25 0x00007fde340c001d in WebCore::RenderObject::layoutIfNeeded (this=0xc03988) at ../../Source/WebCore/rendering/RenderObject.h:520 #26 0x00007fde340abacc in WebCore::RenderBlock::layoutPositionedObjects (this=0x1d6d698, relayoutChildren=false) at ../../Source/WebCore/rendering/RenderBlock.cpp:2140 #27 0x00007fde340ab7a4 in WebCore::RenderBlock::layoutOnlyPositionedObjects (this=0x1d6d698) at ../../Source/WebCore/rendering/RenderBlock.cpp:2090 #28 0x00007fde340a74b1 in WebCore::RenderBlock::layoutBlock (this=0x1d6d698, relayoutChildren=false, pageLogicalHeight=0) at ../../Source/WebCore/rendering/RenderBlock.cpp:1137 #29 0x00007fde340a7382 in WebCore::RenderBlock::layout (this=0x1d6d698) at ../../Source/WebCore/rendering/RenderBlock.cpp:1122 #30 0x00007fde340c001d in WebCore::RenderObject::layoutIfNeeded (this=0x1d6d698) at ../../Source/WebCore/rendering/RenderObject.h:520 #31 0x00007fde340abacc in WebCore::RenderBlock::layoutPositionedObjects (this=0x1d6cff8, relayoutChildren=false) at ../../Source/WebCore/rendering/RenderBlock.cpp:2140 #32 0x00007fde340ab7a4 in WebCore::RenderBlock::layoutOnlyPositionedObjects (this=0x1d6cff8) at ../../Source/WebCore/rendering/RenderBlock.cpp:2090 #33 0x00007fde340a74b1 in WebCore::RenderBlock::layoutBlock (this=0x1d6cff8, relayoutChildren=false, pageLogicalHeight=0) at ../../Source/WebCore/rendering/RenderBlock.cpp:1137 #34 0x00007fde340a7382 in WebCore::RenderBlock::layout (this=0x1d6cff8) at ../../Source/WebCore/rendering/RenderBlock.cpp:1122 #35 0x00007fde340c001d in WebCore::RenderObject::layoutIfNeeded (this=0x1d6cff8) at ../../Source/WebCore/rendering/RenderObject.h:520 #36 0x00007fde340abacc in WebCore::RenderBlock::layoutPositionedObjects (this=0x1d61198, relayoutChildren=false) at ../../Source/WebCore/rendering/RenderBlock.cpp:2140 ...
Alejandro G. Castro
Comment 26 2011-02-27 08:50:16 PST
(In reply to comment #25) > This commit is causing a lot of crashes in the gtk debug bots: > I meant, assertion failures sorry.
WebKit Review Bot
Comment 27 2011-02-27 09:01:43 PST
http://trac.webkit.org/changeset/79784 might have broken GTK Linux 32-bit Debug
Adam Roben (:aroben)
Comment 28 2011-02-27 09:55:27 PST
This patch is causing assertion failures on Windows. See bug 55321.
Adam Roben (:aroben)
Comment 29 2011-02-28 09:06:42 PST
Since the assertion failures have been happening for many days now, and a fix is not imminent, we're rolling out the change. Bug 55386 tracks the rollout.
Adam Roben (:aroben)
Comment 30 2011-02-28 09:08:09 PST
Reopening since this change is getting rolled out.
Rik Cabanier
Comment 31 2011-03-01 17:01:59 PST
Created attachment 84327 [details] Updated patch with version that doesn't assert in debug mode This time I verified that the layout tests also pass in debug mode :-)
WebKit Review Bot
Comment 32 2011-03-01 17:31:06 PST
Attachment 84327 [details] did not pass style-queue: Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'LayoutTests/ChangeLog', u'LayoutTests/tran..." exit_code: 1 Source/WebCore/css/CSSStyleSelector.cpp:5590: l is incorrectly named. Don't use the single letter 'l' as an identifier name. [readability/naming] [4] Total errors found: 1 in 8 files If any of these errors are false positives, please file a bug against check-webkit-style.
Rik Cabanier
Comment 33 2011-03-03 11:05:58 PST
Created attachment 84588 [details] Updated patch with version that doesn't assert in debug mode + fixed style
WebKit Review Bot
Comment 34 2011-03-03 11:08:59 PST
Attachment 84588 [details] did not pass style-queue: Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'LayoutTests/ChangeLog', u'LayoutTests/tran..." exit_code: 1 Source/WebCore/css/CSSStyleSelector.cpp:5672: l is incorrectly named. Don't use the single letter 'l' as an identifier name. [readability/naming] [4] Total errors found: 1 in 8 files If any of these errors are false positives, please file a bug against check-webkit-style.
Rik Cabanier
Comment 35 2011-03-03 11:10:32 PST
Created attachment 84591 [details] Updated patch with version that doesn't assert in debug mode + fixed style
WebKit Review Bot
Comment 36 2011-03-03 11:13:22 PST
Attachment 84591 [details] did not pass style-queue: Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'LayoutTests/ChangeLog', u'LayoutTests/tran..." exit_code: 1 Source/WebCore/css/CSSStyleSelector.cpp:5672: l is incorrectly named. Don't use the single letter 'l' as an identifier name. [readability/naming] [4] Total errors found: 1 in 8 files If any of these errors are false positives, please file a bug against check-webkit-style.
Rik Cabanier
Comment 37 2011-03-03 11:15:01 PST
Created attachment 84594 [details] Updated patch with version that doesn't assert in debug mode + fixed style
Dave Hyatt
Comment 38 2011-03-04 10:53:17 PST
Comment on attachment 84594 [details] Updated patch with version that doesn't assert in debug mode + fixed style r=me
WebKit Commit Bot
Comment 39 2011-03-04 14:23:14 PST
Comment on attachment 84594 [details] Updated patch with version that doesn't assert in debug mode + fixed style Rejecting attachment 84594 [details] from commit-queue. Failed to run "['./Tools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '--bot-id=cr-jail-8', 'build-..." exit_code: 2 Last 500 characters of output: ....................................................................................................................................................................................................................... inspector ........... inspector/audits . inspector/audits/audits-panel-functional.html -> failed Exiting early after 1 failures. 12760 tests run. 307.03s total testing time 12759 test cases (99%) succeeded 1 test case (<1%) had incorrect layout 8 test cases (<1%) had stderr output Full output: http://queues.webkit.org/results/8087715
Pavel Feldman
Comment 40 2011-03-04 14:46:30 PST
Comment on attachment 84594 [details] Updated patch with version that doesn't assert in debug mode + fixed style > inspector/audits/audits-panel-functional.html -> failed I am working on this flaky test, should be robust in 24 hours.
WebKit Commit Bot
Comment 41 2011-03-04 15:04:04 PST
The commit-queue encountered the following flaky tests while processing attachment 84594 [details]: inspector/audits/audits-panel-functional.html bug 55776 (authors: apavlov@chromium.org, pfeldman@chromium.org, and rniwa@webkit.org) The commit-queue is continuing to process your patch.
WebKit Commit Bot
Comment 42 2011-03-04 15:06:06 PST
Comment on attachment 84594 [details] Updated patch with version that doesn't assert in debug mode + fixed style Clearing flags on attachment: 84594 Committed r80379: <http://trac.webkit.org/changeset/80379>
WebKit Commit Bot
Comment 43 2011-03-04 15:06:15 PST
All reviewed patches have been landed. Closing bug.
WebKit Review Bot
Comment 44 2011-03-04 15:25:18 PST
http://trac.webkit.org/changeset/80379 might have broken Leopard Intel Release (Build)
Rik Cabanier
Comment 45 2011-03-09 16:10:22 PST
Created attachment 85254 [details] latest fix for leopard
Tony Gentilcore
Comment 46 2011-03-09 16:23:12 PST
I verified that attachment 85254 [details] is identical to attachment 84594 [details] which dhyatt r+'d except for a new static_cast<float> to fix the SL build. Since I rolled this back in https://bugs.webkit.org/show_bug.cgi?id=55799, I'm r+'ing to get this going again.
WebKit Commit Bot
Comment 47 2011-03-10 20:09:12 PST
Comment on attachment 85254 [details] latest fix for leopard Clearing flags on attachment: 85254 Committed r80806: <http://trac.webkit.org/changeset/80806>
WebKit Commit Bot
Comment 48 2011-03-10 20:09:19 PST
All reviewed patches have been landed. Closing bug.
Tony Gentilcore
Comment 49 2011-03-13 15:57:16 PDT
Please see bug 56275, this might have broken transitions/default-timing-function.html
Note You need to log in before you can comment on or make changes to this bug.