STR === 1. Click some input to open the virtual keyboard 2. Type "t" repeatedly Actual: The background of some keys are rendered overlapped. See the attached screenshot. Expected: The keyboard UI should be normal.

BTW, this should be a regression on Gecko side, since the styling related code of keyboard has been there for a while. Thanks.

(In reply to Rudy Lu [:rudyl] from comment #1) > BTW, this should be a regression on Gecko side, since the styling related > code of keyboard has been there for a while. > > Thanks. Can you turn off async animation and see if the problem is still there? $EDITOR ./gecko/b2g/app/b2g.js ./build.sh gecko && ./flash.sh gecko

Still could be reproduced with Async Animation disabled. -- pref("layers.offmainthreadcomposition.animate-opacity", false); pref("layers.offmainthreadcomposition.animate-transform", false); -- Rev info: Gecko: 257e1c12c860780818480e8eab80265e7afdc173 Gaia: latest - e78314253db7e2490ce5e4b3d3426db7f0f6df72

(In reply to Rudy Lu [:rudyl] from comment #3) > Still could be reproduced with Async Animation disabled. > -- > pref("layers.offmainthreadcomposition.animate-opacity", false); > pref("layers.offmainthreadcomposition.animate-transform", false); > > > -- > Rev info: > > Gecko: 257e1c12c860780818480e8eab80265e7afdc173 > Gaia: latest - e78314253db7e2490ce5e4b3d3426db7f0f6df72 Could you try pref("layers.offmainthreadcomposition.enabled", false); ? Thanks.

Yes, the issue is still there with, -- pref("layers.offmainthreadcomposition.animate-opacity", false); pref("layers.offmainthreadcomposition.animate-transform", false); pref("layers.offmainthreadcomposition.enabled", false); Thanks for the suggestions.

Can reproduce on Unagi with tip revisions. If you slowly but steadily keep pressing "t" the spaces between keys in the top row will get smaller and smaller.

Commenting out the following line fixes the issue: https://github.com/ttaubert/gaia/blob/19f9de5cf63035e6cfe06affa73a1db6f5eedaa9/apps/keyboard/style/keyboard.css#L162 Seems to be a Gecko rendering issue.

CCing some people who can help.

(In reply to Tim Taubert [:ttaubert] from comment #7) > Commenting out the following line fixes the issue: > > https://github.com/ttaubert/gaia/blob/ > 19f9de5cf63035e6cfe06affa73a1db6f5eedaa9/apps/keyboard/style/keyboard. > css#L162 > > Seems to be a Gecko rendering issue. Not "top: -5.3rem;" I assume? Which CSS property was it? Looks like some kind of overdraw issue.

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #9) > (In reply to Tim Taubert [:ttaubert] from comment #7) > > Commenting out the following line fixes the issue: > > > > https://github.com/ttaubert/gaia/blob/ > > 19f9de5cf63035e6cfe06affa73a1db6f5eedaa9/apps/keyboard/style/keyboard. > > css#L162 > > > > Seems to be a Gecko rendering issue. > > Not "top: -5.3rem;" I assume? Which CSS property was it? I linked the revision so that the line doesn't change. It was exactly the "top" rule. If I comment that out there's no strange overlapping after a few key presses.

This visible outcome of this issue is minor, the keyboard repaints correctly after it is dismissed and reopened, and there does not appear to be any impact on keyboard function. basecamp-

(In reply to Lawrence Mandel [:lmandel] from comment #11) > This visible outcome of this issue is minor, the keyboard repaints correctly > after it is dismissed and reopened, and there does not appear to be any > impact on keyboard function. basecamp- Agreed. Also, the state is reset when hiding and showing the keyboard again.

We should at least track it for v1.x though.

Add Bug 826152 as dependency of Bug 835404, since Thinker found that the transparent background of keyboard iframe might affect performance. Also tracked in this page, https://intranet.mozilla.org/B2GKeyboardPerformance

Adding UX-Most-Wanted per Rudy's comment: > Add Bug 826152 as dependency of Bug 835404, since Thinker found that the > transparent background of keyboard iframe might affect performance. Anything that might improve keyboard performance is top priority for quality improvement and should at least be investigated further. It's icing on the cake that this bug would also solve an ugly glitch.

Something to try: while holding down a key on the second row from the top, press keys on the top row. When I do that, I see the enlarged key painted over with semi-transparent black.

I strongly believe this is a duplicate of bug 821533. That bug has a similar failure, and only occurs on linux with X rendering disabled. That should have us rendering with cairo/pixman, the same as we do with b2g. I haven't been able to make much progress debugging this on device, I'd really appreciate it if someone could make a reduced test case. I think following the same steps as bug 821533 on linux should give you an environment where it happens, and then we need a standalone version of the keyboard app to see if it happens.

We're seeing this resolved by markup changes in bug #860318 which remove background images. Will follow up and close as resolved once those land.

I'm concerned that we might run into the underlying rendering issue with other apps or web content, even though we've worked around it for the keyboard. I don't think we're even sure what combination of things causes it — I've heard speculation that it's something to do with button elements with transparent backgrounds, but a trivial case of that doesn't reproduce it. What we do know is that it can occur with B2G's rendering setup, and it can be caused by HTML and CSS as we make them available to apps (as opposed to being XUL-specific).

Let's close this for now since it is not reproducible after bug 860318 lands, and it is not easy to track down the combination to make this issue happen again.