Closed
Bug 1033921
Opened 10 years ago
Closed 10 years ago
[NFC] Shrinking UI incorrectly when using swipe gesture to change apps
Categories
(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)
Tracking
(blocking-b2g:2.0+, 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
Reporter | ||
Updated•10 years ago
|
blocking-b2g: --- → 2.0?
Comment 1•10 years ago
|
||
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)
Updated•10 years ago
|
Blocks: edge-gestures
Comment 2•10 years ago
|
||
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)
Assignee | ||
Comment 6•10 years ago
|
||
Can be reproduced.
The shrinking UI always recognize the rightest sheet instead of the current sheet.
Assignee | ||
Comment 7•10 years ago
|
||
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.
Updated•10 years ago
|
Target Milestone: --- → 2.0 S6 (18july)
Updated•10 years ago
|
Blocks: b2g-NFC-2.0
Assignee | ||
Comment 8•10 years ago
|
||
emit 'appopen' event when stack manager did goPrev/goNext operation.
Attachment #8456607 -
Flags: review?(alive)
Assignee | ||
Comment 9•10 years ago
|
||
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 10•10 years ago
|
||
Comment on attachment 8456607 [details]
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-
Comment 11•10 years ago
|
||
(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.
Assignee | ||
Comment 12•10 years ago
|
||
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)
Comment 13•10 years ago
|
||
(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.
Assignee | ||
Comment 14•10 years ago
|
||
Comment on attachment 8456607 [details]
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 15•10 years ago
|
||
Comment on attachment 8456607 [details]
pull request redirect to github
r+ only with tests.
Attachment #8456607 -
Flags: review?(alive) → review+
Assignee | ||
Comment 16•10 years ago
|
||
Thanks for review.
add shrink UI test with willbeactive case. wait for TBPL pass to land.
Assignee | ||
Comment 17•10 years ago
|
||
merged to gaia master https://github.com/mozilla-b2g/gaia/commit/dd8a9e53a9e519e8875fd3fe1a25eec5a1ad9486
thanks!
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(gbrander)
Resolution: --- → FIXED
Assignee | ||
Updated•10 years ago
|
status-b2g-v2.0:
--- → affected
status-b2g-v2.1:
--- → fixed
Assignee | ||
Updated•10 years ago
|
Whiteboard: [p=3]
Comment 18•10 years ago
|
||
Reporter | ||
Comment 19•10 years ago
|
||
Verified on
Gaia aa4f795b81c6147d67c4f06009e166debcf8856e
Gecko https://hg.mozilla.org/releases/mozilla-aurora/rev/0ec0b9ac39f0
BuildID 20140716160201
Version 32.0a2
Status: RESOLVED → VERIFIED
Comment 20•10 years ago
|
||
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
Comment 21•10 years ago
|
||
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.
Description
•