957678 - [B2G][SMS] Message text field is blocked by keyboard when attempting to send an SMS through Dialer app

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)

Description

[Nikolai Khristoforov]

Attachment: Logcat

When the user attempts to send an SMS through the Dialer app, the Message text field gets blocked by the keyboard which prevents the user from seeing what they are typing. This only occurs when sending the message through the Dialer app call log and after accessing the Message Settings page.

Repro Steps:
1) Updated Buri to BuildID: 20140106004001
2) Make sure the Dialer call log is populated.
3) Open the Dialer app and select a number in the call log.
4) Select the "Send Message" option.
5) Select the ellipsis (...) button then select the "Settings" option.
6) Select the "X" button to go back to the SMS page.
7) Select the Message text field for the keyboard to appear.
8) Type something using the keyboard.

Actual:
The Message text field is blocked by the keyboard preventing the user from seeing what they're typing.

Expected:
The text field would be visible.

Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20140106004001
Gaia: 35a60b82f8cf2d759939a350e2dadbb9d8b2f5dc
Gecko: a43cb4b322d3
Version: 28.0a2
Firmware Version: V1.2_20131115

Repro frequency: 100%
See attached: Logcat and Screenshot

Comment 1

[Nikolai Khristoforov]

Attachment: ProperTextField

Comment 2

[Nikolai Khristoforov]

Attachment: ErrorTextField

Comment 3

[Nikolai Khristoforov]

I cannot repro the bug on 1.2 because the path to Message Settings from the New SMS screen does not exist which is essential in reproducing the bug.

Device: Buri 1.2 COM
BuildID: 20140106004001
Gaia: 8441587c3b352e052fee07665c21fd192540f19f
Gecko: d552c08a72d0
Version: 26.0
RIL Version: 01.02.00.019.102
Firmware Version: V1.2_20131115

Comment 4

[Jason Smith [:jsmith]]

We shouldn't ever end up in a case where the keyboard overlays a text field that the user is typing into - this basically means the user won't know what he/she is typing.

Comment 5

[Nikolai Khristoforov]

This issue is also reproducible by sending an SMS to a contact through the Dialer Contacts app and the actual Contacts app.

Comment 6

[Joe Cheng [:jcheng] (please needinfo)]

triage: 1.3+

Comment 7

[Julien Wajsberg [:julienw]]

Looks like a keyboard issue that is not resizing the app.

Comment 8

[Steve Chung [:steveck]]

Hi Rudy, this bug only reproducible when opening the message app from other app(dialer/contact) and open the settings app. Is there any possible bugs in this flow will cause the view failed to update the height with keyboard shows up?

Comment 9

[Tim Guan-tin Chien [:timdream] (please needinfo)]

No, updating the height is the responsibility of input management.

Comment 10

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

As Tim said, this should be in the bucket of System app's input management part.
Will take a look if I have free cycles.

Comment 11

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

It seems the activity_window_#ID would not be correctly resized after we came back from settings,

The following line would not be invoked to resize it because activityCallee (in this case should be Message app) has been reset to null.
this.activityCallee.resize();

--
https://github.com/mozilla-b2g/gaia/blob/f79532e643cba364c6531c5dbbc7549c3875bebf/apps/system/js/window.js#L671

Comment 12

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Taking. I have WIP patch for v1.3.

Comment 13

[Mozilla Shepherd (This account is used for automation and doesn't receive bugmail)]

Attachment: mozilla-b2g:v1.3 PR#15523

Comment 14

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 8362434 [details] [review]
mozilla-b2g:v1.3 PR#15523

v1.3 specific patch.

Comment 15

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 8362434 [details] [review]
mozilla-b2g:v1.3 PR#15523

r+ for v1.3 only

Comment 16

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Attachment: Github: https://github.com/mozilla-b2g/gaia/pull/15527

master patch.

Comment 17

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 8362458 [details] [review]
Github: https://github.com/mozilla-b2g/gaia/pull/15527

Code is ok but please try to consider adding unit test for appWindow and appWindowManager.

Comment 18

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 8362458 [details] [review]
Github: https://github.com/mozilla-b2g/gaia/pull/15527

+ tests and change the approach of finding the requestOpen() app to call.

Comment 19

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 8362434 [details] [review]
mozilla-b2g:v1.3 PR#15523

Need update.

Comment 20

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 8362434 [details] [review]
mozilla-b2g:v1.3 PR#15523

Updated. I still utilized a while loop to find the AppWindow-to-launch in the v1.3 specific patch.

Comment 21

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 8362458 [details] [review]
Github: https://github.com/mozilla-b2g/gaia/pull/15527

r+ but travis seems broken.

Comment 22

[Julien Wajsberg [:julienw]]

Travis is back but there are jshint and unit test failures ;)

Comment 23

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Alive Kuo [:alive][NEEDINFO!][:艾莉芙] from comment #21)
> Comment on attachment 8362458 [details] [review]
> Github: https://github.com/mozilla-b2g/gaia/pull/15527
> 
> r+ but travis seems broken.

Fix, will merge when green.

(In reply to Julien Wajsberg [:julienw] from comment #22)
> Travis is back but there are jshint and unit test failures ;)

Thanks!

Comment 24

[Tim Guan-tin Chien [:timdream] (please needinfo)]

master: https://github.com/mozilla-b2g/gaia/commit/cb01e66ea19103bec60a3985258b804b24438b49
v1.3: https://github.com/mozilla-b2g/gaia/commit/bf12a73cd908417ff474f03876dbe237f46a5089