Bug 19058

Summary: [Transforms] problems with contentEditable and transformed elements (caret drawing)
Product: WebKit Reporter: Duncan Wilcox <duncan>
Component: HTML EditingAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: bdakin, lon, mitz, simon.fraser
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Mac   
OS: OS X 10.5   
Bug Depends on: 15671    
Bug Blocks:    
Attachments:
Description Flags
testcase
none
Testcase: <input type="text"> also broken
none
no caret in contenteditable in iframe in conjunction with -webkit-transform and an overlapping element none

Duncan Wilcox
Reported 2008-05-14 13:57:34 PDT
The testcase I'm attaching shows how even a no-op transform (like translate(0px) or scale(1)) make editing a contentEditable area behave erratically. Specifically: - no flashing caret - clicking on the text places the cursor in the wrong position - the caret is shown at wrong offsets Actual scaling or translation transforms amplify the bad effects.
Attachments
testcase (389 bytes, text/html)
2008-05-14 13:58 PDT, Duncan Wilcox 		no flags
Details
Testcase: <input type="text"> also broken (591 bytes, application/xhtml+xml)
2008-11-25 13:18 PST, Jack Schmidt 		no flags
Details
no caret in contenteditable in iframe in conjunction with -webkit-transform and an overlapping element (2.31 KB, application/zip)
2010-11-05 04:56 PDT, Lon Boonen 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Duncan Wilcox
Comment 1 2008-05-14 13:58:07 PDT
Created attachment 21135 [details] testcase
Jack Schmidt
Comment 2 2008-11-25 13:18:42 PST
Created attachment 25495 [details] Testcase: <input type="text"> also broken The bug not only affects contentEditable, but all input forms. Verified in nightly build WebKit-SVN-r38707.dmg A version with a translate(-640px,0) (instead of translate(0,0)), can hang Mobile Safari on iPhone OS 2.1 (reboot required).
Lon Boonen
Comment 3 2010-11-05 04:56:37 PDT
Created attachment 73056 [details] no caret in contenteditable in iframe in conjunction with -webkit-transform and an overlapping element this reproduces the non-blinking caret. code explains it all
Lon Boonen
Comment 4 2010-11-05 04:59:51 PDT
Google Maps API version 3.2 is causing this bug to proliferate. Google sets style="-webkit-transform:translateZ(0px);" on all tiles in a Map. This is causing unwanted side-effects: 1. invisible caret in contenteditable areas inside an iframe that is (partially) obscured by some html-element (see attachment of comment #3) 2. a white flash every time the first map is drawn and webkit presumably switches to some different rendering scheme Since Google is now using this in Maps the problem is spreading. webkit-transform cannot have side-effects like this... Thank you.
Simon Fraser (smfr)
Comment 5 2010-11-05 10:45:06 PDT
Hmm, this stuff used to work correctly, was fixed in r39069.
Simon Fraser (smfr)
Comment 6 2010-11-05 11:18:12 PDT
(In reply to comment #4) > Google Maps API version 3.2 is causing this bug to proliferate. > > Google sets style="-webkit-transform:translateZ(0px);" on all tiles in a Map. > > This is causing unwanted side-effects: > > 1. invisible caret in contenteditable areas inside an iframe that is (partially) obscured by some html-element (see attachment of comment #3) > > 2. a white flash every time the first map is drawn and webkit presumably switches to some different rendering scheme > > Since Google is now using this in Maps the problem is spreading. > webkit-transform cannot have side-effects like this... These issues are unrelated to this bug. Any 3D transform creates compositing layers, and it seems that there are caret drawing issues in those. However, the first two testcases work perfectly. I filed 49079 to cover the compositing/iframes issue.
Simon Fraser (smfr)
Comment 7 2010-11-09 12:14:41 PST
http://trac.webkit.org/changeset/71666
Note You need to log in before you can comment on or make changes to this bug.