Bug 31852 – -webkit-transform:translate3d causes corruption of text in inputs

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: CSS

[David Calhoun]

Created attachment 43812 [details]
reduced test case

With translate3d added to an element, text corruption occurs with a specific arrangement of the HTML elements that follow.  It seems to only affect text text inputs with display:table-row on their parent container.  See the screenshots and the attached test case for more details.

This occurs with the latest nightly (WebKit r51303).  It also occurs on my iPhone, which has this user agent: Mozilla/5.0 (iPhone; U; CPU iPhone OS 3_1_2 like Mac OS X; en-us) AppleWebKit/528.18 (KHTML, like Gecko) Version/4.0 Mobile/7D11 Safari/528.16

[David Calhoun]

Created attachment 43813 [details]
text input corruption in a password field (left)

[David Calhoun]

Created attachment 43814 [details]
text input corruption (right)

Note that when leaving the left password field (blur event), the text becomes "ungarbled".  However the same problem plagues the non-password input field while typing (on the right).

[David Calhoun]

The fix is to add this rule to the stylesheet (thanks to my coworker):

input[type=password], input:focus, textarea {
    -webkit-transform: scale(1,1);
}

[Simon Fraser (smfr)]

Does this still reproduce? Seems OK in Safari 5.0.3 to me.

[Devin Rhode]

When you open a page in an iframe and it uses translate3d, it also seems to corrupt text that is z-index'd above it, OUTSIDE the iframe.

<span>Normal text</span>
<iframe> ...some element has "transform:translate3d(Npx, Mpx, Opx);":</iframe>

The normal text then get's visually altered. The same visual bug occurs when you add the translate3d property right to the text element itself.

[Devin Rhode]

Further, David Calhoun's hack of using -webkit-transform: scale(1,1); on an element doesn't work for regular text nodes. A <span> tag in my case, obviously it would be for all text elements. This is all whti Chrome 17/beta

[Simon Fraser (smfr)]

Devin, I still can't reproduce, even in a recent WebKit nightly build on Mac.

[Yehonatan Daniv]

Working on 17.0.963.65 (Developer Build 124586 Linux) Ubuntu 11.10

I see corruption of caret positioning in a text input:

http://jsfiddle.net/errFm/1/

[Yehonatan Daniv]

(In reply to comment #8)
> Working on 17.0.963.65 (Developer Build 124586 Linux) Ubuntu 11.10
> 
> I see corruption of caret positioning in a text input:
> 
> http://jsfiddle.net/errFm/1/

Also note that the scale(1,1) doesn't fix that

[Brent Fulgham]

Safari, Chrome, and Firefox show the same rendering behavior for this test case. I do not believe any further compatibility issue remains.