Skip to content
  • simon.fraser@apple.com's avatar
    2008-12-06 Simon Fraser <simon.fraser@apple.com> · 2b2b6ce0
    simon.fraser@apple.com authored
            Reviewed by Dave Hyatt
    
            https://bugs.webkit.org/show_bug.cgi?id=15671
    
            Fix caret rendering to behave correctly with transforms:
            * Rename caretRect() methods to localCaretRect() and
              absoluteCaretBounds() as appropriate
            * Fix localCaretRect() methods to return a rect in the
              appropriate coordinates.
            * Pass tx, ty down through the paintCaret() methods, after fixing them
              up to account for differences between contents coords, and renderer-local
              coords (via RenderBlock::offsetForContents()).
            * Remove m_caretPositionOnLayout from SelectionController, and instead
              call invalidateSelection() from RenderLayer::scrollToOffset(), because
              we can no longer assume simple x/y offsets from scrolling with transforms.
            * Move the logic to compute which RenderObject actually paints the caret into
              SelectionController::caretRenderer(), rather than having it in RenderBlock.
            * SelectionController now computes and caches a local caret rect. For invalidation,
              it computes the absolute bounds of that (possibly transformed) local rect.
              The local rect is computed in the coordinate system of the RenderObject that
              will paint the caret (this may require offsetting from the actual renderer
              at the start of the selection).
            * Fix LayoutState(RenderObject* root) to take transforms into account
            * Make offsetFromContainer() a virtual method on RenderObject, and implement
              the RenderObject version. It's used to map from selection start renderer
              to caret renderer.
    
            Test: fast/transforms/transformed-caret.html
    
    
    git-svn-id: http://svn.webkit.org/repository/webkit/trunk@39069 268f45cc-cd09-0410-ab3c-d52691b4dbfc
    2b2b6ce0