Closed Bug 957678 Opened 7 years ago Closed 7 years ago

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

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:1.3+, b2g-v1.3 fixed)

RESOLVED FIXED
blocking-b2g 1.3+
Tracking Status
b2g-v1.3 --- fixed

People

(Reporter: nkhristoforov, Assigned: timdream)

Details

(Whiteboard: dogfood1.3)

Attachments

(5 files)

Attached file 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
Attached image ProperTextField
Attached image ErrorTextField
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
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.
blocking-b2g: --- → 1.3?
This issue is also reproducible by sending an SMS to a contact through the Dialer Contacts app and the actual Contacts app.
triage: 1.3+
blocking-b2g: 1.3? → 1.3+
Flags: needinfo?(rlu)
Looks like a keyboard issue that is not resizing the app.
Component: Gaia::SMS → Gaia::Keyboard
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?
No, updating the height is the responsibility of input management.
Component: Gaia::Keyboard → Gaia::System::Input Mgmt
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.
Flags: needinfo?(rlu)
Assignee: nobody → rlu
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
Component: Gaia::System::Input Mgmt → Gaia::System::Window Mgmt
Taking. I have WIP patch for v1.3.
Assignee: rlu → timdream
Comment on attachment 8362434 [details] [review]
mozilla-b2g:v1.3 PR#15523

v1.3 specific patch.
Attachment #8362434 - Flags: review?(alive)
Comment on attachment 8362434 [details] [review]
mozilla-b2g:v1.3 PR#15523

r+ for v1.3 only
Attachment #8362434 - Flags: review?(alive) → review+
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.
Attachment #8362458 - Flags: review?(alive)
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.
Attachment #8362458 - Flags: review?(alive)
Comment on attachment 8362434 [details] [review]
mozilla-b2g:v1.3 PR#15523

Need update.
Attachment #8362434 - Flags: review+
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.
Attachment #8362434 - Flags: review?(alive)
Attachment #8362434 - Flags: review?(alive) → review+
Comment on attachment 8362458 [details] [review]
Github: https://github.com/mozilla-b2g/gaia/pull/15527

r+ but travis seems broken.
Attachment #8362458 - Flags: review?(alive) → review+
Travis is back but there are jshint and unit test failures ;)
(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!
You need to log in before you can comment on or make changes to this bug.