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.
Created attachment 21135 [details] testcase
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).
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
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.
Hmm, this stuff used to work correctly, was fixed in r39069.
(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.
http://trac.webkit.org/changeset/71666