LayoutTests:
authorjusting <justing@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Wed, 25 Oct 2006 01:37:04 +0000 (01:37 +0000)
committerjusting <justing@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Wed, 25 Oct 2006 01:37:04 +0000 (01:37 +0000)
commit75206d9c6f3f2f9499787783ecdb98c80b4127e6
tree7d7b0f1874c85caf51cdcc213e0314c8f3dd0028
parent999b6309034ca6d4c316598284e16f73f95c7087
LayoutTests:

        Reviewed by darin

        <http://bugs.webkit.org/show_bug.cgi?id=10993>
        GMail Editor: Caret doesn't always position itself after list marker

        * editing/execCommand/create-list-1-expected.checksum: Added.
        * editing/execCommand/create-list-1-expected.png: Added.
        * editing/execCommand/create-list-1-expected.txt: Added.
        * editing/execCommand/create-list-1.html: Added.

        Fixed:
        * editing/execCommand/create-list-with-hr-expected.checksum:
        * editing/execCommand/create-list-with-hr-expected.png:
        * editing/execCommand/create-list-with-hr-expected.txt:
        * editing/execCommand/create-list-with-hr.html:
        * editing/execCommand/remove-list-1-expected.checksum:
        * editing/execCommand/remove-list-1-expected.png:
        * editing/execCommand/remove-list-1-expected.txt:
        * fast/text/attributed-substring-from-range-001-expected.txt:

WebCore:

        Reviewed by darin

        <http://bugs.webkit.org/show_bug.cgi?id=10993>
        GMail Editor: Caret doesn't always position itself after list marker

        List creation uses moveParagraphs to push content into list items.
        moveParagraphs uses a TextIterator to restore selections after moves.
        Some characters emitted by the TextIterator had bad ranges associated
        with them.  rangeFromLocationAndLength would skip past the range it
        should have used when asked for ranges of length 0.

        * editing/TextIterator.cpp:
        (WebCore::TextIterator::TextIterator): No longer need to initialize a
        removed member variable.
        (WebCore::TextIterator::advance): An extra newline is emitted when leaving
        some blocks.  Use the same range for this newline as for the first newline.
        We should remove this code and just emit two '\n's.
        (WebCore::TextIterator::handleTextNode): Setup m_range.
        (WebCore::TextIterator::handleTextBox): Ditto.
        (WebCore::TextIterator::handleReplacedElement): Ditto.
        (WebCore::TextIterator::handleNonTextNode): Ditto.
        (WebCore::TextIterator::exitNode): Use an m_range from the last VisiblePosition
        in the block we're leaving to that VP after that one.
        (WebCore::TextIterator::emitCharacter): This function now takes in the start
        and the end of the range associated with the emited character, and sets up m_range.
        (WebCore::TextIterator::range): Return m_range.  If it is null (we are atEnd),
        return the end of the range used to create the iterator, as a convenience to
        callers that use call range() on an iterator that is atEnd.
        (WebCore::SimplifiedBackwardsTextIterator::SimplifiedBackwardsTextIterator):
        Same as the changes made to TextIterator's constructor.
        (WebCore::SimplifiedBackwardsTextIterator::advance): Use a null m_range instead of
        a null m_positionNode to signal that we're finished.
        (WebCore::SimplifiedBackwardsTextIterator::handleTextNode): Ditto.
        (WebCore::SimplifiedBackwardsTextIterator::handleReplacedElement): Similar to changes
        made to TextIterator.
        (WebCore::SimplifiedBackwardsTextIterator::emitCharacter): Ditto.
        (WebCore::SimplifiedBackwardsTextIterator::emitNewline): Simplified.
        (WebCore::SimplifiedBackwardsTextIterator::range): Similar to the changes made to
        TextIterator::range.
        (WebCore::CharacterIterator::range): This function assumed that an iterator's
        range() was safe to modify.
        (WebCore::TextIterator::rangeFromLocationAndLength):
        If the range we're looking for starts in the current chunk, this function assumed
        that if the chunk started in a text node, it would end in the same text node.  This
        is no longer the case.
        If the range we're looking for starts in the middle of the current chunk, I assume
        that the chunk is inside a text node, because those are the only chunks with length
        greater than one at the moment.
        If the range we're looking for is a zero length range that starts/ends at the end of the
        current chunk, we used to return the start of the next chunk, but that's wrong and
        is what caused this bug.
        * editing/TextIterator.h:
        (WebCore::TextIterator::atEnd): The iterator is atEnd when m_range is null.
        (WebCore::SimplifiedBackwardsTextIterator::atEnd):
        * editing/visible_units.cpp:
        (WebCore::previousBoundary): Cleaned up by using a convenience function.
        (WebCore::nextBoundary): Ditto.

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@17276 268f45cc-cd09-0410-ab3c-d52691b4dbfc
17 files changed:
LayoutTests/ChangeLog
LayoutTests/editing/execCommand/create-list-1-expected.checksum [new file with mode: 0644]
LayoutTests/editing/execCommand/create-list-1-expected.png [new file with mode: 0644]
LayoutTests/editing/execCommand/create-list-1-expected.txt [new file with mode: 0644]
LayoutTests/editing/execCommand/create-list-1.html [new file with mode: 0644]
LayoutTests/editing/execCommand/create-list-with-hr-expected.checksum
LayoutTests/editing/execCommand/create-list-with-hr-expected.png
LayoutTests/editing/execCommand/create-list-with-hr-expected.txt
LayoutTests/editing/execCommand/create-list-with-hr.html
LayoutTests/editing/execCommand/remove-list-1-expected.checksum
LayoutTests/editing/execCommand/remove-list-1-expected.png
LayoutTests/editing/execCommand/remove-list-1-expected.txt
LayoutTests/fast/text/attributed-substring-from-range-001-expected.txt
WebCore/ChangeLog
WebCore/editing/TextIterator.cpp
WebCore/editing/TextIterator.h
WebCore/editing/visible_units.cpp