Build: Device - Unagi Date - 12/10/2012 Mozilla Beta Prefs - Identity is prefed on Steps: 1. Go to marketplace 2. Select to login 3. Select the enter your email address text field Expected: The keyboard should come up with the persona dialog being responsive to a smaller dialog. Actual: See screenshot. It looks like the dialog isn't handling responsive design to when a dialog becomes smaller too well.

(cc :jcarpenter) Jason, I have been seeing this, too. As a quick test, I tried turning off native identity. That keeps the same UI, but causes the dom methods to be executed in the js shim. So it circumvents the trusty UI and appears as a new tab in b2g. When I do this, I see the dialog laid out normally, with no white blob. (It works similarly on android.) In other words, the white blob appears only when the dialog is rendered inside the trusty ui. This makes me suspect that the problem here may not be an identity bug, but something in either the Trusty UI layout or other system styles.

Triage: does it break usage? or it simple looks weird from the UI?

(In reply to Joe Cheng from comment #2) > Triage: does it break usage? or it simple looks weird from the UI? Combination of this issue + bug 820059 basically right now makes it incredibly difficult to complete a login. When we decide to pref this on (once the "smoketest" of it passes), both of these bugs would be classified as smoketest blockers (this becomes a smoketest when this prefs on for context).

Triage: Looks like a major usability bug

it's debatable if this is a trusted UI bug or a keyboard bug

I am not seeing this with the mozPay flow for the mock payment provider, so it might be related to the content loaded within the trusted UI.

Pointer to Github pull-request

So it turns out after digging into this with Jed that the attached patch will not fix the original issue. Apparently this bug reproduces on slow network connections when connecting to persona - whether that be the shim or the native implementation. It's still worth landing, but what's landed doesn't inherently block basecamp. So this will need approval.

Comment on attachment 690993 [details] Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/6957 I believe what this patch does will cause new regression because keyboard resize is canceled but no anywhere to deal with it again.

I'm actually going to wontfix this - the point made in comment 9 and a past bug indicates we shouldn't do this.

Looks like Bug 818575 - Content becomes white after tapping into a text area from a shortcut made on the homepage. I don't think this is a keyboard issue since that white area was not be painted by keyboard app. itself. Hi Jason, Do you mean by closing this issue so that we could track "white area issue" with Bug 818575? Thanks.

(In reply to Rudy Lu [:rudyl] from comment #11) > Looks like Bug 818575 - Content becomes white after tapping into a text area > from a shortcut made on the homepage. > > I don't think this is a keyboard issue since that white area was not be > painted by keyboard app. itself. > > Hi Jason, > > Do you mean by closing this issue so that we could track "white area issue" > with Bug 818575? > > Thanks. I actually morphed this bug into doing the don't resize logic, but after hearing Alive's comments, I marked it as a won't fix since a blocking regression will occur if we implement this.

Comment on attachment 690993 [details] Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/6957 No need for review then.