STR: 1. Open https://login.persona.org 2. Tap "Sign In" button 3. When keyboard opens, enter an email address 4. RESULT: No text is displayed in the text field! 5. Pinch the web page to manually resize it 6. RESULT: The email address in the text field is now visible!

Could have sworn there was a bug on file for this, but I'm failing to find this.

Is this still a problem? What device, what build? Seems to work on my unagi, Dec 6 build, beta channel.

(In reply to Milan Sreckovic from comment #2) > Is this still a problem? What device, what build? Seems to work on my > unagi, Dec 6 build, beta channel. I think this happened for me on a more recent build, but I can go check again.

I can reproduce this with a 2012-12-17 build. Chris, is this something you can work on?

I think this is a painting bug, not a keyboard bug. I don't have time to investigate further at the moment..

Jeff, can you see if we can get the regression window?

(In reply to Jason Smith [:jsmith] from comment #3) > (In reply to Milan Sreckovic from comment #2) > > Is this still a problem? What device, what build? Seems to work on my > > unagi, Dec 6 build, beta channel. > > I think this happened for me on a more recent build, but I can go check > again. Well, either I was dreaming or the site changed, but my phone now fails as well with 20121206...

Removing the regression flag, not sure that it actually is.

This reduced test case shows the same problem.

This only seems to happen with 13pt font.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #10) > This only seems to happen with 13pt font. 13px I mean.

Adding a few others who might have ideas.

Some more interesting information: If the height of the text box is explicitly set the problem does not occur. However, I was not able to explicitly set the height of the text box to a height that matched the intrinsic-height. We also do seem to be drawing the text, it's just not showing up for some reason. Either it's clipped out or we draw something on top of it. I haven't figured out which yet.

bug 818575 has more content in it. People are working on it in core.

I'm not convinced this is a dup. We seem to be painting the text in the wrong place i.e in both cases (working and not) we paint the glyph at y position of 23. In the broken case it ends up being adjusted to 13. This is happening because there's a CTM on the cairo_context of -10. I'm not sure why yet though.

jeff, any update since you last looked at this?

(In reply to Faramarz (:faramarz) from comment #17) > jeff, any update since you last looked at this? No. I've been on vacation.

The difference in translation comes from FrameLayerBuilder::DrawThebesLayer:3268 aContext->Translate(aLayer->GetResidualTranslation() - gfxPoint(offset.x, offset.y)) In this case offset is different between a text field that works and one that doesn't. The layer bounds are also different between the two cases. In the working case the bounds seem to be the entire page. In the non-working case it seems limited to the textbox.

We are indeed creating an additional layer for the text. We appear to be doing so because a display port is set on the content because we need to be able to scroll it.

So we're triggering this bug because we build a layer when we hit this case http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsGfxScrollFrame.cpp#2089 So that explains what's special about this text box. Next I'll try to figure out why the rendering goes wrong.

This reproduces the problem by using overflow:auto on a div.

I'm closing this and have opened a new bug 826378 for the remaining problem.

So Faramarz and I ran into this issue after this patch landed with Twitter and the IBahn site at the hotel. Is this really fixed? I'm going to double check again, otherwise, I'll file a followup.

Definitely confirmed it's happening on Twitter's sign on page with today's build. Followup coming.