1179400 - [Window Management] Half the screen will be black after opening a share activity when the keyboard is up

Status: VERIFIED FIXED

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

Description

[Adam Alldredge [:AdamA][Inactive]]

Attachment: logcat

Description:
If the user has the keyboard up and clicks on the add attachment button in messages or tries to add a photo to a contact then half of the screen will be black where the keyboard was previously.

Repro Steps:
1) Update a Aries to 20150701145139
2) Enter Contacts
3) Add a new contact
4) Click on a field to invoke the keyboard
5) Click on the photo area to add a picture
6) press cancel
7) Observe Contact screen

Actual:
Half the screen is black

Expected:
It is expected that the phone displays on most of the screen.

Environmental Variables:
Device: Aries 2.5 (Full Flash)
Build ID: 20150701145139
Gaia: 5a39ff43424e92e73c468b8f00a6c62476f30177
Gecko: 2ec00565de09
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 42.0a1 (2.5)
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0

Repro frequency: 10/10
See attached: video clip(http://youtu.be/X7ODerBdwFo), logcat

Comment 1

[Adam Alldredge [:AdamA][Inactive]]

Attachment: Messages - Half black screen

Comment 2

[Adam Alldredge [:AdamA][Inactive]]

Attachment: Email - Half Black screen

Comment 3

[Adam Alldredge [:AdamA][Inactive]]

This issue DOES NOT occur in a previous Spark 2.5 build.

Environmental Variables:
Device: Aries 2.5
BuildID: 20150619225606
Gaia: 4c06ed88ddccaba8dc941e5006bd2a9e57306f07
Gecko: 7c1a6b1151a1539186b950a144387e2d7f378d1b
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 41.0a1 (2.5) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0

Result:
user can still see the whole screen after opening a share activity with the keyboard.

Comment 4

[Etienne Segonzac (:etienne)]

Might be bug 1176769 :/
Good news is, we should be able to make the STR into an integration test to prevent future regressions.

Comment 5

[Etienne Segonzac (:etienne)]

Scratch that, bug 1176769 landed after this bug was found.

Comment 6

[Etienne Segonzac (:etienne)]

Might be bug 1176926 :)

Comment 7

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Ouch...

Comment 8

[Tim Guan-tin Chien [:timdream] (please needinfo)]

I can confirm this is due to bug 1176926.

Comment 9

[Tim Guan-tin Chien [:timdream] (please needinfo)]

I have identified the cause to be the state inconsistency between InputWindowManager#hideInputWindow and InputWindowManager#hideInputWindowImmediately.

With bug 1176926, InputWindowManager#hideInputWindow will unset |this._currentWindow| without dispatch keyboardhide event in the same function loop. In the case of comment 0, originally we would rely on InputWindowManager#hideInputWindowImmediately to resize the window at the same function loop of "activityrequesting" event. Since by the time we reach there |this._currentWindow| is null, InputWindowManager#hideInputWindowImmediately returns early and did not resize the window back to full.

By the time hideInputWindow actually dispatches keyboardhide event, the topmost UI has already been replaced by the activity dialog -- HierarchyManager#boardcast thus stops the system-resize event at SystemDialogManager, before AppWindowManager could act on it.

I think the quick fix here is to add yet another flag to have hideInputWindowImmediately() do stuff even if there is a pending async hideInputWindow()? This is tricky and is not going to be pretty...

Comment 10

[Tim Guan-tin Chien [:timdream] (please needinfo)]

I have a working patch ready. Just need to finish up with tests.

Comment 11

[Adam Alldredge [:AdamA][Inactive]]

This issue DOES occur on the latest flame 2.5 build.

Environmental Variables:
Device: Flame 2.5 [Full Flash]
BuildID: 20150702010204
Gaia: b901c8b7be2119f4df42781aac1401ed12765460
Gecko: f5e3bacfb60e
Gonk: a4f6f31d1fe213ac935ca8ede7d05e47324101a4
Version: 42.0a1 (2.5) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0

Comment 12

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Attachment: Github: https://github.com/mozilla-b2g/gaia/pull/30814

Etienne, as you said I added Gij tests to ensure this don't regress.

John, not sure if you are available to review this or not -- if not just cancel the review and I will count on Etienne on this.

Comment 13

[Etienne Segonzac (:etienne)]

Comment on attachment 8629226 [details] [review]
Github: https://github.com/mozilla-b2g/gaia/pull/30814

Looks good to me. Thanks for cleaning up & adding to the integration tests!

Looks like we're not hitting the race when running in b2g-desktop but it's still valuable to have this test in place.

Comment 14

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Etienne Segonzac (:etienne) from comment #13)
> Looks like we're not hitting the race when running in b2g-desktop but it's
> still valuable to have this test in place.

Yeah, it's depend on the order between receiving blur and activity-launching mozChromeEvent in System app. Probably yet another inproc/oop difference.

master: https://github.com/mozilla-b2g/gaia/commit/3a89bbc00ffc807b5ca34b7bbf19e48bdefdc641

Comment 15

[Adam Alldredge [:AdamA][Inactive]]

This issue is verified fixed on Flame 2.5 and Spark 2.5.

Result: 
The full screen is used when attaching images with the keyboard up.

Environmental Variables:
Device: Flame 2.5
BuildID: 20150706010204
Gaia: dc6c18c0dea7af3c40bfff86c530fd877d899dc4
Gecko: 136c41fca853
Gonk: a4f6f31d1fe213ac935ca8ede7d05e47324101a4
Version: 42.0a1 (2.5) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0

Device: Aries 2.5
BuildID: 20150706103023
Gaia: dc6c18c0dea7af3c40bfff86c530fd877d899dc4
Gecko: cef11c3e86c3
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 42.0a1 (2.5) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0