Closed Bug 1033921 Opened 5 years ago Closed 5 years ago

[NFC] Shrinking UI incorrectly when using swipe gesture to change apps

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(blocking-b2g:2.0+, b2g-v2.0 verified, b2g-v2.1 verified)

VERIFIED FIXED
2.0 S6 (18july)
blocking-b2g 2.0+
Tracking Status
b2g-v2.0 --- verified
b2g-v2.1 --- verified

People

(Reporter: ashiue, Assigned: gasolin)

References

Details

(Whiteboard: [p=3])

Attachments

(2 files)

Gaia      90605754e9bdbe20f3999522f9e1aec600c422a4
Gecko     https://hg.mozilla.org/releases/mozilla-aurora/rev/0bffc7e5d8a2
BuildID   20140702160207
Version   32.0a2

STR:
1. Open multiple apps which can NFC share
2. Using swipe gesture to change apps
3. Tap 2 phones together and check shrinking UI (http://youtu.be/624rOi1xtgU)
4. Open another app which cannot NFC share
5. Using swipe gesture to change to an app which can NFC share
6. Tap 2 phones together and check shrinking UI (http://youtu.be/qpHW_sgbMoA)

Expected result:
1. Step 3 should show shrinking UI correctly
2. Step 6 should show shrinking UI correctly

Actual result:
1. Step 3, shrinking UI would show the final launch app screen
2. Step 6 could not show shrinking UI
blocking-b2g: --- → 2.0?
Should we block swipe in NFC pairing in v2.0 release?
Or we just need to cancel the pairing and clear the state after swiping?
Flags: needinfo?(firefoxos-ux-bugzilla)
Flagging Gordon on this as I try not overload Francis while Jacqueline, Peter and Casey are out. 

I am not sure this is a blocker: does the state just never clear, making the screen "stuck"?
Flags: needinfo?(firefoxos-ux-bugzilla) → needinfo?(gbrander)
Triage: +'ing, functional breakage.
blocking-b2g: 2.0? → 2.0+
Assign to Greg for investigation.
Assignee: nobody → gweng
take it
Assignee: gweng → gasolin
Can be reproduced.

The shrinking UI always recognize the rightest sheet instead of the current sheet.
shrinking UI maintain it's own app stack. It will call `_switchTo` function while get `appopen` event. So it will always recognize the rightest sheet if edge gesture did not popped this event while swiping between apps.
Target Milestone: --- → 2.0 S6 (18july)
emit 'appopen' event when stack manager did goPrev/goNext operation.
Attachment #8456607 - Flags: review?(alive)
more explaination:

`shrinking UI` maintain it's own app stack and depends on `appopen` event to switch to current app.
`edge gesture` use `stack manager` to handle goPrev/goNext operation, but it does not notify others that the current app is changed, so the module maintain its own app stack will not get update.
Comment on attachment 8456607 [details] [review]
pull request redirect to github

1. Does UX confirm to enable swipe navigation during NFC pairing?
2. StackManager should not dispatch any app* event for appWindow.
3. appopen is fired each time the swipe done in _handle_swipein().
Attachment #8456607 - Flags: review?(alive) → review-
(In reply to Fred Lin [:gasolin] from comment #9)
> more explaination:
> 
> `shrinking UI` maintain it's own app stack and depends on `appopen` event to
> switch to current app.
> `edge gesture` use `stack manager` to handle goPrev/goNext operation, but it
> does not notify others that the current app is changed, so the module
> maintain its own app stack will not get update.

The broadcast is to enable a nice continuous swipe so the real opened event is delayed after 800ms.
What we could do (if UX wants) is to call appIn.publish('opening') or a new event when it goes in the queue.
The issue is about NFC pairing AFTER doing swipe. So either remain/disable swipe navigation during NFC pairing is not the case. 
(It looks fine that shinking UI won't overlap the screen while swiping)
(In reply to Alive Kuo [:alive][NEEDINFO!][Berlin 7/14-7/18] from comment #11)
> (In reply to Fred Lin [:gasolin] from comment #9)
> > more explaination:
> > 
> > `shrinking UI` maintain it's own app stack and depends on `appopen` event to
> > switch to current app.
> > `edge gesture` use `stack manager` to handle goPrev/goNext operation, but it
> > does not notify others that the current app is changed, so the module
> > maintain its own app stack will not get update.
> 
> The broadcast is to enable a nice continuous swipe so the real opened event
> is delayed after 800ms.
> What we could do (if UX wants) is to call appIn.publish('opening') or a new
> event when it goes in the queue.

Fine, so the problem is StackManager is asynchronous with AppWindowManager.
There's 800ms delay that StackManager has different active app info from AppWindowManager after each swipe. This is problematic.

Since queueBroadcast calls queueShow/queueHide in AppWindow, it makes sense to publish 'willbeactive' and 'willbeinactive' inside queueShow/queueHide and then ask AppWindowManager or ShrinkingUI to update active app info.
Comment on attachment 8456607 [details] [review]
pull request redirect to github

published 'willbeactive' and 'willbeinactive' inside queueShow/queueHide and then ask ShrinkingUI to update active app info.

Test with open gallery(NFC), browser(NFC), settings(non NFC) app and works fine

please kindly review it again.
Attachment #8456607 - Flags: review- → review?(alive)
Comment on attachment 8456607 [details] [review]
pull request redirect to github

r+ only with tests.
Attachment #8456607 - Flags: review?(alive) → review+
Thanks for review.

add shrink UI test with willbeactive case. wait for TBPL pass to land.
merged to gaia master https://github.com/mozilla-b2g/gaia/commit/dd8a9e53a9e519e8875fd3fe1a25eec5a1ad9486

thanks!
Status: NEW → RESOLVED
Closed: 5 years ago
Flags: needinfo?(gbrander)
Resolution: --- → FIXED
Whiteboard: [p=3]
Verified on
Gaia      aa4f795b81c6147d67c4f06009e166debcf8856e
Gecko     https://hg.mozilla.org/releases/mozilla-aurora/rev/0ec0b9ac39f0
BuildID   20140716160201
Version   32.0a2
Status: RESOLVED → VERIFIED
Attached video verify_video.MP4
This issue has been verified successfully on Flame v2.1
See attachment: verify_video.MP4
Reproducing rate: 0/5
Flame 2.1 versions:
Gaia-Rev        5655269098c7e82254e56933f1af05b4abe2a2f3
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/86608c9389b5
Build-ID        20141204001201
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141204.034958
FW-Date         Thu Dec  4 03:50:09 EST 2014
Bootloader      L1TC00011880
This issue has been verified successfully on Flame v2.0
See attachment: verify_video.MP4
Reproducing rate: 0/5
Flame 2.0 versions:
Gaia-Rev        8d1e868864c8a8f1e037685f0656d1da70d08c06
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/ff1100ba2ab8
Build-ID        20141204000228
Version         32.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141204.040425
FW-Date         Thu Dec  4 04:04:36 EST 2014
Bootloader      L1TC00011880
You need to log in before you can comment on or make changes to this bug.