Closed Bug 854759 Opened 9 years ago Closed 9 years ago

[System] when the key board showed and the same time attention screen closed , the app size will be uncorrect.

Categories

(Firefox OS Graveyard :: Vendcom, defect)

ARM
Gonk (Firefox OS)
defect
Not set
critical

Tracking

(blocking-b2g:leo+, b2g18 verified, b2g18-v1.0.0 wontfix, b2g18-v1.0.1 wontfix, b2g-v1.1hd fixed)

RESOLVED FIXED
blocking-b2g leo+
Tracking Status
b2g18 --- verified
b2g18-v1.0.0 --- wontfix
b2g18-v1.0.1 --- wontfix
b2g-v1.1hd --- fixed

People

(Reporter: vend_qichao.lu, Assigned: rudyl)

References

Details

(Whiteboard: [LeoVB+])

Attachments

(1 file)

Dear All:
In version V1.0.1.
There would be a uncorrect in some apps that if the key board showed and the same time attention screen closed.
for exmample , do as blew:
First , use another phone(Phone A) to call the FireFox OS phone such as Unagi(Phone B).
Then , on the Unagi:
1.accept the call
2.click the "home key" to return homescreen
3.find the "SMS" icon and launch the "SMS" app
4.create a new message to let the keyboard show

OK, let's end off the call on the Phone A.

We can see that app's height would be calculator as the keyboard not shows but actually the keyboard just shows up now! It will hide the "input" label behind the keyboard view.

Can any one help me ?
Hi Steven

This a critical issue, please assign it, thanks!
Component: Gaia::System → Vendcom
Rudy, please help on this. Thanks!
Assignee: styang → rlu
This issue could be reproduced.
It seems like an issue of window_manager when handling attention screen close case.

Will look into the details later.
Comment on attachment 743548 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/9483

[Root Cause]
After the attention screen (call screen) is hidden, setAppSize() will be called again, but it won't take keyboard height into account.
That's why the app window is resized as its normal size.

[Solution]
1. Make KeyboardManager expose keyboard height via KeyboardManager.getHeight().
2. consider the keyboard height in the app resize handler in window manager for this case.

Dear Alive,

Could you help take a look at this patch?
Thank you.
Attachment #743548 - Flags: review?(alive)
Comment on attachment 743548 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/9483

As offline discussion, we plan to 
1) remove setAppHeight in WM
2) change the keyboardchange event, use KM.height instead to monitor KM status.
Attachment #743548 - Flags: review?(alive)
Comment on attachment 743548 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/9483

Hi Alive,

The pull request has been updated to address the comments and as we discussed.
Please help review it again.

Thank you.
Attachment #743548 - Flags: review?(alive)
Comment on attachment 743548 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/9483

Excellent, r=me and I trust that you must have tested as much as you could.
Attachment #743548 - Flags: review?(alive) → review+
Alive,

Thanks for the review.

Gaia master:
https://github.com/mozilla-b2g/gaia/commit/6b49d56cdb5a09d92e17f829e54ceed2deb2df74
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
No longer blocks: 870708
Blocks: 840147, 877903
blocking-b2g: --- → leo?
Nomiating this bug as leo? for bug 840147 and bug 877903 because we need its |getHeight()| function to set iframe size correctly.
We need attention - please give leo+ in order to checkin the dependent bug 840147/bug 877903,
they need quicker checkin to avoid conflict.

If this is not updated tonight, we in the long run will cherry-pick this bug's commit in bug 840147's v1-train commit.
We only see https://bugzilla.mozilla.org/show_bug.cgi?id=840147#c32 but no comments in bug 840147 or bug 877903 that suggest this has been verified as a blocker for either.

We're at the point that where we don't take changes to avoid conflict, unless it there really isn't an alternative.
I think there's alternative but may cause regressions, see the bugs caused by v1-train patch of bug 840147 and bug 877903.

Why this happens? Because there're difference between master and v1-train,
master with this patch, has a simple and improved code architecture.

YES this is not a blocker indeed, but it's necessary for things to move forward.

If you don't accept this, we can't avoid to (1) just cherry-pick this in the patch, or else (2) 're-write' this patch in 840147.

(3) Or the worst, use a very dirty workaround way and may be regression-ful.

BTW, maybe the easiest way is to leo- 840147 and 877903 because it takes a big patch and just is the root cause that why we need this bug to go to v1-train.

(In reply to Alex Keybl [:akeybl] from comment #12)
> We're at the point that where we don't take changes to avoid conflict,
> unless it there really isn't an alternative.

I don't think conflict matters. Resolve it. We do that every time we make a v1-train patch because there're more and more difference between master and v1-train.
Triage - leo+ per comment 13 recommendation.
blocking-b2g: leo? → leo+
Verified on Leo V1.1, this issue no longer reproduces on Leo device.
When the keyboard slides up it's not blocking the input field

Environmental  Variables:
Build ID: 20130717070237
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/582e3a7018b0
Gaia: c506c50adaaebcf729ac3c27887ba2931ab79040
Platform Version: 18.1
RIL Version: 01.01.00.019.138
Whiteboard: [LeoVB+]
v1.1.0hd: d10346a787e70268c63b592edded848c53c16dcf
You need to log in before you can comment on or make changes to this bug.