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!

Rudy, please help on this. Thanks!

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.

Pointer to Github pull-request

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.

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.

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.

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.

Alive, Thanks for the review. Gaia master: https://github.com/mozilla-b2g/gaia/commit/6b49d56cdb5a09d92e17f829e54ceed2deb2df74

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.

v1-train https://github.com/mozilla-b2g/gaia/commit/d10346a787e70268c63b592edded848c53c16dcf v1.1.0hd https://github.com/mozilla-b2g/gaia/commit/34b064180559dbe64ddea219e247431ec188912d

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

v1.1.0hd: d10346a787e70268c63b592edded848c53c16dcf