Timeline
Jul 17, 2004:
- 9:59 PM Changeset in webkit [7050]
-
- 63 copies2 deletes in tags/WebCore-125~8
This commit was manufactured by cvs2svn to create tag
'WebCore-125~8'.
- 9:59 PM Changeset in webkit [7049] by
-
- 2 edits in branches/Safari-1-2-branch/WebCore
- versioning for next SUPanMoccasin submission (SAP fixes), WebCore-125.8
- 9:57 PM Changeset in webkit [7048] by
-
- 3 edits in branches/Safari-1-2-branch/WebCore
Roll this Security Update change out for the next SUPanMoccasin
submission. Security Update changes can't be included in Software
Updates.
2004-07-09 Chris Blumenberg <cblu@apple.com>
Allowed my change for 3715785 to compile on Jaguar.
Reviewed by kocienda.
- kwq/WebCoreBridge.h:
- kwq/WebCoreBridge.mm: (-[WebCoreBridge domain]): new, allows access to the domain without using the DOM API which doesn't exist on Jaguar
Jul 16, 2004:
- 3:56 PM Changeset in webkit [7047] by
-
- 3 edits in trunk/JavaScriptCore
Reviewed by Maciej.
- fixed <rdar://problem/3714644> REGRESSION (125.8-146): bugzilla submit link hangs browser with javascript
- kjs/array_object.cpp: (ArrayProtoFuncImp::call): Check for undefined type for args[0] the same way we were already checking for args[1]. In this case, args was zero-length, but we were treating args[0] like an integer anyway. Resulted in some code looping from a NAN value to 4, taking approximately forever.
- JavaScriptCore.pbproj/project.pbxproj: version wars
- 3:20 PM Changeset in webkit [7046] by
-
- 2 edits in trunk/WebCore
Fix for 3726471, need to ensure that it's safe to do updateRendering from within layout, since isContentEditable
relies on it. The fix is to just recalcStyle up front before beginning the layout, so that all of our renderobjects
will be up-to-date.
Reviewed by john
- khtml/khtmlview.cpp: (KHTMLView::layout):
- 2:51 PM Changeset in webkit [7045] by
-
- 3 edits in branches/Safari-1-2-branch/WebCore
Reviewed by vicki.
- merge these changes from HEAD for SUPanMoccasin, 3730021
2004-07-06 Ken Kocienda <kocienda@apple.com>
Reviewed by me
- khtml/html/html_tableimpl.cpp: (HTMLTableElementImpl::addChild): Added a better comment in the code I just checked in a few minutes ago.
2004-07-06 Ken Kocienda <kocienda@apple.com>
Reviewed by Hyatt
Fix for this bug:
<rdar://problem/3672377> assertion failure in AppendNodeCommandImpl::doApply
due to non-0 exception code trying to insert a DIV markup string
The solution was to revert to the code that was rolled out, and removing
the child checks from NodeImpl::checkAddChild. However, this time, I added
code very similar to this check into the code that runs while HTML is
being parsed to build up tables. This code relies on child-add failure
to ensure the proper construction of well-formed tables (as gross as that
sounds), so the check needs to be retained there. No other code seems to
be so affected. Layout tests are unchanged by this patch.
- khtml/html/html_tableimpl.cpp: (HTMLTableElementImpl::addChild):
- khtml/xml/dom_nodeimpl.cpp: (NodeImpl::checkAddChild):
- 2:29 PM Changeset in webkit [7044] by
-
- 2 edits in branches/Safari-1-2-branch/WebCore
Reviewed by vicki.
- merge this change from HEAD for SUPanMoccasin, 3730017
2004-07-14 David Hyatt <hyatt@apple.com>
Fix for 3595073, setting innerHTML on a <table> should work.
Reviewed by rjw
- khtml/html/html_elementimpl.cpp: (HTMLElementImpl::createContextualFragment):
- 2:19 PM Changeset in webkit [7043] by
-
- 2 edits in trunk/WebCore
Reviewed by Hyatt
Fix for this bug:
<rdar://problem/3722153> Random crash while typing (DOM::NodeImpl::parentNode (this=0x0))
- khtml/editing/htmlediting_impl.cpp: (khtml::DeleteSelectionCommandImpl::doApply): This check merely makes the code more robust. I do not understand how Grant ended up with null start or end blocks in the case of his bug report, but by adding two null checks, the code is now hardened a bit in case it happens again.
- 2:14 PM Changeset in webkit [7042] by
-
- 3 edits in trunk/WebCore
Reviewed by Hyatt
Fix for these bugs:
<rdar://problem/3730785> Crash when arrow navigation goes to empty table cell
<rdar://problem/3730790> Caret does not blink when placed in empty table cell
- khtml/rendering/render_block.cpp: (khtml::RenderBlock::paintObject): Caret node's renderer might be this block, so don't block the painting of the caret in this case. This was the case in 3730790. We had the right geometry for the caret but blocked its painting.
- khtml/xml/dom_position.cpp: (DOM::Position::previousLinePosition): Rework the logic here. This function asserted that the new position we would navigate to had a line box, but empty table cells, for instance will not. So, deal with this situation as well. The end result is a function that worked like it did before in cases where the previous line position has a line box, but now also will allow navigation to work when it does not. (DOM::Position::nextLinePosition): Ditto.
- 1:37 PM Changeset in webkit [7041] by
-
- 2 edits in trunk/WebCore
Reviewed by Hyatt
Fix for this bug:
<rdar://problem/3687216> editable inline causes crash when focused
- khtml/xml/dom_docimpl.cpp: (DocumentImpl::relinquishesEditingFocus): Add null check for rootEditableElement. (DocumentImpl::acceptsEditingFocus): Ditto.
- 1:25 PM Changeset in webkit [7040] by
-
- 2 edits in trunk/LayoutTests
Return Panther baseline to layout tests.
- 1:17 PM Changeset in webkit [7039] by
-
- 2 adds in trunk/LayoutTests/fast/compact
Add a layout test for the crashing compact case.
- 1:15 PM Changeset in webkit [7038] by
-
- 2 edits in trunk/WebCore
Fix for 3709337, crash when using display: compact. Need to make sure that the isCompact() check in bidi.cpp is
also checking for RenderBlocks, since otherwise you match text nodes (and that's just wrong).
Reviewed by kocienda
- khtml/rendering/bidi.cpp: (khtml::RenderBlock::layoutInlineChildren):
- 11:00 AM Changeset in webkit [7037] by
-
- 3 edits in trunk
change version number to '153u'. the tree is open!
- 10:55 AM Changeset in webkit [7036]
-
- 3 copies in tags/Safari-152
This commit was manufactured by cvs2svn to create tag 'Safari-152'.
- 10:55 AM Changeset in webkit [7035] by
-
- 6 edits in trunk
Safari-152 stamp
Jul 15, 2004:
- 5:05 PM Changeset in webkit [7034] by
-
- 2 edits in trunk/WebCore
Fix for 3625611, images offset on first visit to page. The method for determining the last clean line was
flawed and would incorrectly miss dirty lines that occurred after the first clean line.
Reviewed by john
- khtml/rendering/bidi.cpp: (khtml::RenderBlock::determineEndPosition):
- 10:20 AM Changeset in webkit [7033] by
-
- 2 edits in trunk/WebCore
Reviewed by John
Fix for this bug:
<rdar://problem/3587601> reproducible assertion failure in Blot deleting text, then image at Yahoo.com
- khtml/editing/htmlediting_impl.cpp: (khtml::DeleteCollapsibleWhitespaceCommandImpl::deleteWhitespace): Relax assertion that nodes are text nodes during the walk of eligible nodes that could possibly be deleted. Change the assertion to an conditional check for text nodes. We may have unrendered nodes in the mix here (as is the case in the bug where the assertion failed on an AREA element), and the conditional check is sufficient to skip them while leaving the delete logic we want unperturbed.
