Caret rects should be reworked to not rely on absolute position.
*** Bug 21907 has been marked as a duplicate of this bug. ***
RenderText::caretRect() calls absolutePositionForContent(), which fails to take transforms into account.
This is another case, like bug 21906, where someone is trying to draw an absolute rectangle, but there's a transform in the parent chain which changes the CTM. The caret drawing is going to have to be "more local".
Created attachment 25002 [details] WIP patch, makes caret painting use local coords
Created attachment 25118 [details] WIP patch 2 This patch has problems with scrolled textareas because the renderer used to compute the caret coords isn't necessarily the one calling paintCaret(); see RenderBlock::paintCaret().
Created attachment 25182 [details] Final patch, changlog. Patch includes a new base for the one existing LayoutTest that shows a transformed caret. I can add more if appropriate. All pixel tests pass with this patch.
Created attachment 25204 [details] Testcase for arrow key navigation with transforms
Created attachment 25209 [details] Final patch, doesn't break arrow navigation
Filed bug 22305 on improving arrow navigation with transforms.
Comment on attachment 25209 [details] Final patch, doesn't break arrow navigation + // First compute a rect local to the rendere at the selection start Typo: you meant "renderer" "// because it's m_frame is always 0." it's should be its "+ , m_beginMinWidth(0) + , m_endMinWidth(0)" This seems irrelevant to the patch? Not that I'm complaining, just curious. r=me
(In reply to comment #10) > "+ , m_beginMinWidth(0) > + , m_endMinWidth(0)" > > This seems irrelevant to the patch? Not that I'm complaining, just curious. Yes, it's not relevant to the caret changes, but just fixing some variable that I noticed during debugging were not initialized.
M WebKit/mac/ChangeLog M WebKit/mac/WebView/WebFrame.mm M WebKit/qt/ChangeLog M WebKit/qt/Api/qwebpage.cpp M WebKit/gtk/webkit/webkitwebview.cpp M WebKit/gtk/ChangeLog M WebKit/win/ChangeLog M WebKit/win/WebView.cpp M WebCore/editing/mac/SelectionControllerMac.mm M WebCore/editing/SelectionController.h M WebCore/editing/DeleteSelectionCommand.cpp M WebCore/editing/VisiblePosition.cpp M WebCore/editing/SelectionController.cpp M WebCore/editing/VisiblePosition.h M WebCore/ChangeLog M WebCore/WebCore.base.exp M WebCore/page/Frame.h M WebCore/page/AccessibilityRenderObject.cpp M WebCore/page/Frame.cpp M WebCore/html/HTMLElement.cpp M WebCore/rendering/RenderObject.cpp M WebCore/rendering/RenderFlow.h M WebCore/rendering/RenderBox.h M WebCore/rendering/RenderFlow.cpp M WebCore/rendering/RenderSVGInlineText.h M WebCore/rendering/RenderObject.h M WebCore/rendering/RenderLayer.cpp M WebCore/rendering/RenderSVGInlineText.cpp M WebCore/rendering/RenderText.cpp M WebCore/rendering/RenderBox.cpp M WebCore/rendering/RenderBlock.cpp M WebCore/rendering/RenderBlock.h M WebCore/rendering/LayoutState.cpp M WebCore/rendering/RenderText.h M LayoutTests/platform/mac/fast/transforms/transformed-focused-text-input-expected.checksum A LayoutTests/platform/mac/fast/transforms/transformed-caret-expected.png M LayoutTests/platform/mac/fast/transforms/transformed-focused-text-input-expected.png A LayoutTests/platform/mac/fast/transforms/transformed-caret-expected.checksum A LayoutTests/platform/mac/fast/transforms/transformed-caret-expected.txt M LayoutTests/ChangeLog A LayoutTests/fast/transforms/transformed-caret.html r39069 = 2b2b6ce0b2190e0531a3182661dd483b8202f0b9 (trunk)
And one more pixel test updated: Committed r39074 M LayoutTests/platform/mac/fast/forms/search-transformed-expected.png M LayoutTests/platform/mac/fast/forms/search-transformed-expected.checksum M LayoutTests/ChangeLog r39074 = 75efff3244d98c9f0f7a2dc6000ce143bfa4a6a0 (trunk)
Has this really ben resolved? I'm still seeing exactly this issue in Chrome.
Please open a new bug with a testcase.
Bug 18751 covers an existing caret drawing problem with transforms.
True, but then this issue isn't really "RESOLVED FIXED". It's a bit misleading. Regardless, thanks for pointing me to the linked bug report. I'll keep an eye on it.
No, wait, that bug (18751) says that the caret blinking problem was split off into this one. Am I missing something here?
I have reproduced the issue in a jsfiddle. I'm using the isotope plugin in my project, so I used it in the jsfiddle to show this issue. Isotope uses the scale3d transform. When this transform is not used, the issue is not observed. To turn off transforms in isotope, simply add "transformsEnabled: false" to the passed options. http://jsfiddle.net/5Rqv8/ To see the issue, focus any textbox. The caret won't be blinking. Type and see that the caret still isn't blinking. Arrow key to the right and see that the caret doesn't move. Type again and see that the text shows up where the caret should be and also moves the caret into position.
Caret blinking problems are usually repaint issues. Could you please file a separate bug with a test case? If you CC me, I'm happy to take a look. Thanks!
*** Bug 94985 has been marked as a duplicate of this bug. ***