User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; aff-kingsoft-ciba; Zune 4.7) Steps to reproduce: 【Repro Steps*】： 1、open messages app,and create a new mms 2、Click back icon to exit mms editing Actual results: no response when click back icon 【Test Count*】：20 【Found Count*】：1 【Log*】： 【Network environment】： 【Resume operation】： 【Carrier】： Expected results: we should always can exit mms editing
Looping Gaia folks.
Which gaia version do you use ? Can we have the log from logcat ? Can we have a video ? FTR I can't reproduce this on the master version of the sms app. Thanks !
still the question in comment 3
hi,julien,sorry for the delay. gaia：c0ea0a4943dc8d3751b07f5b5c5d3abe06364a14 gecko：170f9e477571127cd40997fa2abe262ed43f0e4d gonk-misc：ca9192d7ef6037016d4723647d86b72f7a410633 this issue occurs at a very low ratio,please check the attachment file for log info.
sorry,forget the zip attachment,there is no log info in it. I will upload the log info later,sorry again.
Hi, In the image attachment I've seen a weird behaviour of the panel which contains the keyboard (that's why the app has not the full height). As Julien said, I can not reproduce this issue with yesterday's build. Could you define the Steps to reproduce? Has the keyboard any weird behaviour? THanks!
yep, it looks like we don't resize when the keyboard is hidden.
I wonder if this could happen when we go back while the focus is inside an attachment iframe.
hi,all the issue can be reproduce at very low ratio. Can you give us some insight how to get useful logs for you to analyze keyboard issue, we have got some phone that can reproduce keyboard related issue,for example,keyboard can not be shown up.
You can try to do: adb logcat | grep Gecko | tee logfile.txt while reproducing. But I doubt we'll have anything useful in it. The most useful thing would be a steps to reproduce at 100%. Also, I'd like to know what happens after this. Can you recover from this situation ? What disturbs me here is that we actually have a "security code" that should make you go back even if we don't get the resize (see ). It was added a long time ago and should be on all release branches.  https://github.com/mozilla-b2g/gaia/blob/master/apps/sms/js/thread_ui.js#L594
Vivien just saw it in the contact app, he thinks this is a regression of the new keyboard management. However I don't think the new keyboard management is in 1.1hd so... I don't really know. Needinfo Rudy Lu then. And also :alive because the resize is handled by the system app. So it could be one of those :)
Hi Julien, If the new keyboard management you mentioned means the 3rd-party IME framework we landed a few days ago, then that part did not go to hd branch, since it is v1.2 feature work. :)
(In reply to Julien Wajsberg [:julienw] from comment #10) > I wonder if this could happen when we go back while the focus is inside an > attachment iframe. To me if blur occurs and then resize work should be done correctly. The only thing I could figure out now is blur doesn't occur so keyboard app doesn't modify its url and then keyboard manager doesn't get mozbrowserlocationchange. Doesn't this only happen in sms attachment?
As you see in the screenshot, the keyboard is correctly hidden, only the app is not resized... I don't have the answer to your question
Hmm, this looks like a rendering issue...if we don't resize correctly, you would see the wallpaper...
Oh, I see. Then we would correctly resize but the inside of the SMS app does not resize. Weird..
I think this works properly now. We have a safe timeout for when we don't detect the resize.