Closed
Bug 1179400
Opened 9 years ago
Closed 9 years ago
[Window Management] Half the screen will be black after opening a share activity when the keyboard is up
Categories
(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)
Tracking
(blocking-b2g:2.5+, b2g-master verified)
People
(Reporter: AdamA, Assigned: timdream)
References
()
Details
(Keywords: regression, Whiteboard: [2.5-Daily-Testing][Spark])
Attachments
(4 files)
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
Reporter | ||
Updated•9 years ago
|
Blocks: Foxfood-papercuts
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-master:
--- → affected
Flags: needinfo?(pbylenga)
Whiteboard: [2.5-Daily-Testing][Spark]
Reporter | ||
Comment 1•9 years ago
|
||
Reporter | ||
Comment 2•9 years ago
|
||
Reporter | ||
Comment 3•9 years ago
|
||
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.
Keywords: regression
Comment 4•9 years ago
|
||
Might be bug 1176769 :/
Good news is, we should be able to make the STR into an integration test to prevent future regressions.
Flags: needinfo?(timdream)
Comment 5•9 years ago
|
||
Scratch that, bug 1176769 landed after this bug was found.
Flags: needinfo?(timdream)
Assignee | ||
Comment 7•9 years ago
|
||
Ouch...
Assignee: nobody → timdream
Status: NEW → ASSIGNED
Flags: needinfo?(timdream)
Assignee | ||
Comment 8•9 years ago
|
||
I can confirm this is due to bug 1176926.
Assignee | ||
Comment 9•9 years ago
|
||
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...
Assignee | ||
Comment 10•9 years ago
|
||
I have a working patch ready. Just need to finish up with tests.
Reporter | ||
Comment 11•9 years ago
|
||
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
Summary: [Aries][Window Management] Half the screen will be black after opening a share activity when the keyboard is up → [Window Management] Half the screen will be black after opening a share activity when the keyboard is up
Assignee | ||
Comment 12•9 years ago
|
||
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.
Attachment #8629226 -
Flags: review?(l90942025)
Attachment #8629226 -
Flags: review?(etienne)
Comment 13•9 years ago
|
||
Comment on attachment 8629226 [details]
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.
Attachment #8629226 -
Flags: review?(etienne) → review+
Updated•9 years ago
|
Attachment #8629226 -
Flags: review?(l90942025)
Assignee | ||
Comment 14•9 years ago
|
||
(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
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 15•9 years ago
|
||
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
Updated•9 years ago
|
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
You need to log in
before you can comment on or make changes to this bug.
Description
•