Bug 19058 – [Transforms] problems with contentEditable and transformed elements (caret drawing)

• Status: RESOLVED
• Resolution: FIXED
• Component: HTML Editing

[Duncan Wilcox]

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.

[Duncan Wilcox]

Created attachment 21135 [details]
testcase

[Jack Schmidt]

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]

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]

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)]

Hmm, this stuff used to work correctly, was fixed in r39069.

[Simon Fraser (smfr)]

(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)]

http://trac.webkit.org/changeset/71666