811509 - login.persona.org does not repaint email text field until user manually resizes the web page (layerizing for scrollable items breaks rendering sometimes)

Status: RESOLVED FIXED

(Firefox OS Graveyard :: General, defect, P1)

Description

[Chris Peterson [:cpeterson]]

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!

Comment 1

[Jason Smith [:jsmith]]

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

Comment 2

[Milan Sreckovic [:milan] (needinfo for best results)]

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

Comment 3

[Jason Smith [:jsmith]]

(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.

Comment 4

[Andrew Overholt [:overholt]]

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

Comment 5

[Chris Peterson [:cpeterson]]

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

Comment 6

[Milan Sreckovic [:milan] (needinfo for best results)]

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

Comment 7

[Milan Sreckovic [:milan] (needinfo for best results)]

(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...

Comment 8

[Milan Sreckovic [:milan] (needinfo for best results)]

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

Comment 9

[Jeff Muizelaar [:jrmuizel]]

Attachment: Reduced test case

This reduced test case shows the same problem.

Comment 10

[Jeff Muizelaar [:jrmuizel]]

This only seems to happen with 13pt font.

Comment 11

[Jeff Muizelaar [:jrmuizel]]

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

13px I mean.

Comment 12

[JP Rosevear [:jpr]]

Adding a few others who might have ideas.

Comment 13

[Jeff Muizelaar [:jrmuizel]]

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.

Comment 14

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

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

Comment 15

[Jeff Muizelaar [:jrmuizel]]

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.

Comment 17

[Faramarz Rashed]

jeff, any update since you last looked at this?

Comment 18

[Jeff Muizelaar [:jrmuizel]]

(In reply to Faramarz (:faramarz) from comment #17)
> jeff, any update since you last looked at this?

No. I've been on vacation.

Comment 19

[Jeff Muizelaar [:jrmuizel]]

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.

Comment 20

[Jeff Muizelaar [:jrmuizel]]

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.

Comment 21

[Jeff Muizelaar [:jrmuizel]]

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.

Comment 22

[Jeff Muizelaar [:jrmuizel]]

Attachment: Further simplified test case

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

Comment 23

[Jeff Muizelaar [:jrmuizel]]

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

Comment 24

[Jason Smith [:jsmith]]

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.

Comment 25

[Jason Smith [:jsmith]]

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