842769 - Going to signup in the Pulse app makes it impossible to see what you are typing in the email/password fields (keyboard covers it)

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::Keyboard, defect)

Description

[Jason Smith [:jsmith]]

Build: B2G 18 2/19/2013
Device: Unagi

Steps:

1. Install the Pulse App - https://marketplace.firefox.com/app/pulse
2. Launch it
3. Try to sign up
4. Start entering text into each field

Expected:

You should be able to have a way to view what you are typing in each field - whether that means the keyboard adjusting to allow you to see the text field or allow you to scroll to the text field to see it.

Actual:

It's impossible to see what you are typing in the email and password fields. The keyboard won't re-adjust to see what you are typing. Additionally, if you try to scroll the dialog to see what you are typing, the content behind the dialog scrolls, but not the dialog. So it becomes impossible to see what you are typing.

Comment 1

[Jason Smith [:jsmith]]

The scrolling issue could potentially be a bug I need to break out separately. Seems strange that scrolling the dialog is scrolling the content in the background.

Comment 2

[Lukas Blakk [:lsblakk] use ?needinfo]

Could this be a Tech Evang bug?

Comment 3

[Jason Smith [:jsmith]]

(In reply to Lukas Blakk [:lsblakk] from comment #2)
> Could this be a Tech Evang bug?

Maybe? Don't know. We would need someone to look at this who knows the keyboard code on if what we are doing is the correct behavior.

Redirecting the question to Rudy - maybe he has some thoughts on this.

Comment 4

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

The signup dialog of Pulse app. is a modal dialog with "position: fixed".

As far as I know, we have a logic in the following frame script to scroll the focused input into the viewport after the app window is resized.
b2g/chrome/content/forms.js

It seems that the "fixed" element is not scrollable so it could not be handled in that logic.

[+cc James to confirm this]

Comment 5

[Lukas Blakk [:lsblakk] use ?needinfo]

Adding qawanted as well - let's break out a separate bug for scrolling if that is something more generic to how we deal with sites & logins.

Comment 6

[Jason Smith [:jsmith]]

(In reply to Lukas Blakk [:lsblakk] from comment #5)
> Adding qawanted as well - let's break out a separate bug for scrolling if
> that is something more generic to how we deal with sites & logins.

I don't follow this statement. Can you clarify?

Comment 7

[Lukas Blakk [:lsblakk] use ?needinfo]

(In reply to Jason Smith [:jsmith] from comment #6)
> (In reply to Lukas Blakk [:lsblakk] from comment #5)
> > Adding qawanted as well - let's break out a separate bug for scrolling if
> > that is something more generic to how we deal with sites & logins.
> 
> I don't follow this statement. Can you clarify?

In comment 1 you mentioned that there might be a separate bug for the scrolling and it looks like the input glitch is perhaps tech evang since it's not clear if we're breaking on the modal dialog or if their login is just not mobile friendly.

Comment 8

[Jason Smith [:jsmith]]

(In reply to Lukas Blakk [:lsblakk] from comment #7)
> (In reply to Jason Smith [:jsmith] from comment #6)
> > (In reply to Lukas Blakk [:lsblakk] from comment #5)
> > > Adding qawanted as well - let's break out a separate bug for scrolling if
> > > that is something more generic to how we deal with sites & logins.
> > 
> > I don't follow this statement. Can you clarify?
> 
> In comment 1 you mentioned that there might be a separate bug for the
> scrolling and it looks like the input glitch is perhaps tech evang since
> it's not clear if we're breaking on the modal dialog or if their login is
> just not mobile friendly.

I don't think there's any conclusion here from development yet that indicates that this is tech evangelism - the discussion about talks about not handling the case when we content follows a position:fixed CSS property on a DOM element that so happens to be a dialog. The way the keyboard works to "focus" a particular element is to actually scroll the text field into view. As Rudy mentions, this is what's not working on this bug. The fact that scrolling generally does not work either just specifies the general concept of the problem here.

The only way we would confirm this to be tech evangelism would be to see this bug reproducing on FF Android as well. If it doesn't, then I'd call this a compatibility bug with our keyboard.

Comment 9

[Jason Smith [:jsmith]]

Comparing this to Android, what I'm seeing is the following:

1. Android does allow you to scroll the dialog content while the keyboard is up
2. The scrolling of content seen in the background reproduces on FF Android as well, but happens after scrolling of the dialog completes

So the problem originally filed here isn't tech evangelism - the bug has to do with handling the case of scrolling the dialog content that's not working, which apparently is the problem here.

The scrolling seen in the background of the app is irrelevant to the issue at hand, however.

Comment 10

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Hi Jason,

Thanks for the info.
I've checked this issue with FF Android but I think it could be reproduced.

You may refer to the following video for my test,
http://youtu.be/Q7HB0M5JXa4
 Device:Galaxy S2
 Firefox version: 19.0.2
 Android version: 4.0.3

I also checked Chrome or built-in Google browser on the same device and they all got the similar symptom.

Thanks.

Comment 11

[Jason Smith [:jsmith]]

Fair enough. Maybe it didn't seem obvious on my end. Probably don't need to chase after this then if it's reproducing elsewhere. Wont fixing.