Closed
Bug 957678
Opened 11 years ago
Closed 11 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)
Tracking
(blocking-b2g:1.3+, b2g-v1.3 fixed)
People
(Reporter: nkhristoforov, Assigned: timdream)
Details
(Whiteboard: dogfood1.3)
Attachments
(5 files)
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
Reporter | ||
Comment 1•11 years ago
|
||
Reporter | ||
Comment 2•11 years ago
|
||
Reporter | ||
Comment 3•11 years ago
|
||
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
status-b2g-v1.3:
--- → affected
Comment 4•11 years ago
|
||
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?
Reporter | ||
Comment 5•11 years ago
|
||
This issue is also reproducible by sending an SMS to a contact through the Dialer Contacts app and the actual Contacts app.
Updated•11 years ago
|
Flags: needinfo?(rlu)
Comment 7•11 years ago
|
||
Looks like a keyboard issue that is not resizing the app.
Component: Gaia::SMS → Gaia::Keyboard
Comment 8•11 years ago
|
||
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?
Assignee | ||
Comment 9•11 years ago
|
||
No, updating the height is the responsibility of input management.
Component: Gaia::Keyboard → Gaia::System::Input Mgmt
Comment 10•11 years ago
|
||
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 | ||
Updated•11 years ago
|
Assignee: nobody → rlu
Comment 11•11 years ago
|
||
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
Assignee | ||
Comment 14•11 years ago
|
||
Comment on attachment 8362434 [details] [review]
mozilla-b2g:v1.3 PR#15523
v1.3 specific patch.
Attachment #8362434 -
Flags: review?(alive)
Comment 15•11 years ago
|
||
Comment on attachment 8362434 [details] [review]
mozilla-b2g:v1.3 PR#15523
r+ for v1.3 only
Attachment #8362434 -
Flags: review?(alive) → review+
Comment 17•11 years ago
|
||
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)
Assignee | ||
Comment 18•11 years ago
|
||
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)
Assignee | ||
Comment 19•11 years ago
|
||
Comment on attachment 8362434 [details] [review]
mozilla-b2g:v1.3 PR#15523
Need update.
Attachment #8362434 -
Flags: review+
Assignee | ||
Comment 20•11 years ago
|
||
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)
Updated•11 years ago
|
Attachment #8362434 -
Flags: review?(alive) → review+
Comment 21•11 years ago
|
||
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+
Comment 22•11 years ago
|
||
Travis is back but there are jshint and unit test failures ;)
Assignee | ||
Comment 23•11 years ago
|
||
(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!
Assignee | ||
Comment 24•11 years ago
|
||
You need to log in
before you can comment on or make changes to this bug.
Description
•