1113050 - [Flame][Notifications]Tap top left in Music Share Menu view,notifcation bar hide and the rocket bar is invoked in background.

Status: RESOLVED FIXED

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

Description

[Elie]

[1.Description]:
[Flame][v2.1][Notifications]Tap top left in Music Share Menu view,notifcation bar hide ,then press Cancel to close Music Share Menu view ,you can see rocket bar has been invoked on Music Share Menu view.
Attchmen:VIDEO0167_Compress.MP4 and logcat.txt
Happen time:9:33

[2.Testing Steps]: 
1.Launch music
2.Tap a song->tap the Share icon
**Music Share Menu view pops up
3.Tap top left in Music Share Menu view


[3.Expected Result]: 
3.Notification bar should not disappear and rocket bar should not be invoked in background.

[4.Actual Result]: 
3.Notification bar disappear and rocket bar is invoked in background.

[5.Reproduction build]: 
Gaia-Rev        97873dca486abf4162a3345e71b375806937bdec
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/ec87f4f41d3d
Build-ID        20141215001202
Version         34.0

[6.Reproduction Frequency]: 
Always Recurrence,5/5
TCID: Free test

Comment 1

[Elie]

Attachment: VIDEO0167_Compress.MP4

Comment 2

[Elie]

Attachment: logcat.txt

Comment 3

[Norry.L.F(Leave from Mozilla)]

> [5.Reproduction build]: 
> Gaia-Rev        97873dca486abf4162a3345e71b375806937bdec
> Gecko-Rev      
> https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/ec87f4f41d3d
> Build-ID        20141215001202
> Version         34.0
> 
Update build infor:
Flame 2.1 build:
Gaia-Rev        14315733e2d265a42f9ab02d1aba191789870f70
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/ddecea83ce6e
Build-ID        20141217001201
Version         34.0

Comment 4

[Sue]

Attachment: logcat_v2.2_1718.txt

This issue can be repro on lasted build Flame 2.2, and there is no status bar at share menu view.
STR:
1.Launch music
2.Tap a song->tap the Share icon
**Music Share Menu view pops up, but there is no status bar
3.Tap top left in Music Share Menu view.
**Rocket bar is invoked in background
Found time:17:18
See attachment:logcat_v2.2_1718.txt and video_v2.2.MP4

Flame 2.2 build:
Gaia-Rev        3554ea9504046646b4679e3a61317c49fc55ca87
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/67c42c076393
Build-ID        20141228010205
Version         37.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141228.045435
FW-Date         Sun Dec 28 04:54:46 EST 2014
Bootloader      L1TC00011880

Comment 5

[Sue]

Attachment: video_v2.2.MP4

Comment 6

[Eric Chang [:ericcc] [:echang]]

Hi Alive, Could you help with this, thanks.

Comment 7

[(inactive after 6/18) Alive Kuo [:alive]]

I think this is a rocketbar/chrome issue. It should not accept the touch event while there is action menu on. More precisely, it seems appChrome is always getting the touch event even there is an overlay on top of it.

Kevin, mind finding someone to take a look?

Comment 9

[Kevin Grandon :kgrandon]

So it looks like the rocketbar is currently opening up from gestures on the top panel[1]. This was implemented in bug 1043284 when we implemented opening the rocketbar from an app-window[2]. Instead we should probably try some other technique for detecting hits, but I'm not sure what the best strategy is at this time. It's likely going to involve moving the event listener to a different dom element though. I'll assign this to myself for now and do some initial investigation.

[1] https://github.com/mozilla-b2g/gaia/blob/db7512ed18485e64b0696c2ff66945f06155cebc/apps/system/js/utility_tray.js#L393
[2] https://github.com/mozilla-b2g/gaia/commit/fd7525af5813dd43b2d3582d250c9838ef0e5531

Comment 10

[Kevin Grandon :kgrandon]

Unassigning from myself until we have an agreed upon strategy to pursue. I took a look and couldn't really find a trivial fix for this in all cases. We could probably go through and fix it for activities, but then some other dialog would likely hit this still and we would be spinning our wheels for a bit trying to cover all cases.

I think one way to fix might be to basically gut utility_tray, and have some app_utility_tray, or some additional forwarder in app_statusbar. If we move logic into the app window we may be able to change the element or strategy that we're using to listen to events.

Etienne - Do you have any preferred approach here?

Comment 11

[Etienne Segonzac (:etienne)]

(In reply to Kevin Grandon :kgrandon from comment #10)
> Unassigning from myself until we have an agreed upon strategy to pursue. I
> took a look and couldn't really find a trivial fix for this in all cases. We
> could probably go through and fix it for activities, but then some other
> dialog would likely hit this still and we would be spinning our wheels for a
> bit trying to cover all cases.
> 
> I think one way to fix might be to basically gut utility_tray, and have some
> app_utility_tray, or some additional forwarder in app_statusbar. If we move
> logic into the app window we may be able to change the element or strategy
> that we're using to listen to events.
> 
> Etienne - Do you have any preferred approach here?

How about having ActionMenus (like the activity chooser) compete in the HierarchyManager and checking |Service.query('getTopMostUI')| in utility_tray.js to make sure we dispatch |global-search-request| from there only the topmost UI is the AppWindowManager/AttentionWindowManager?

Ni-ing Alive to double check this makes sense on the HierarchyManager side.

Comment 12

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Etienne Segonzac (:etienne) from comment #11)
> (In reply to Kevin Grandon :kgrandon from comment #10)
> > Unassigning from myself until we have an agreed upon strategy to pursue. I
> > took a look and couldn't really find a trivial fix for this in all cases. We
> > could probably go through and fix it for activities, but then some other
> > dialog would likely hit this still and we would be spinning our wheels for a
> > bit trying to cover all cases.
> > 
> > I think one way to fix might be to basically gut utility_tray, and have some
> > app_utility_tray, or some additional forwarder in app_statusbar. If we move
> > logic into the app window we may be able to change the element or strategy
> > that we're using to listen to events.
> > 
> > Etienne - Do you have any preferred approach here?
> 
> How about having ActionMenus (like the activity chooser) compete in the
> HierarchyManager and checking |Service.query('getTopMostUI')| in
> utility_tray.js to make sure we dispatch |global-search-request| from there
> only the topmost UI is the AppWindowManager/AttentionWindowManager?
> 
> Ni-ing Alive to double check this makes sense on the HierarchyManager side.

I'd ever considered ActionMenu to be part of the current AppWindow,
so AppChrome in AppWindow could check this.app.hasMenu() and do not publish global-search-request while action menu is opened. But we have an exception now: ImeMenu does not belong to any AppWindow so AppWindow cannot detect it.

That is to say, for now - before we figured out where ImeMenu could go - Etienne's proposal works for me, and let's put ActionMenu between SystemDialog and AppWindowManager in hierarchyManager's priority list.

Comment 13

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Kevin Grandon :kgrandon from comment #10)
> Unassigning from myself until we have an agreed upon strategy to pursue. I
> took a look and couldn't really find a trivial fix for this in all cases. We
> could probably go through and fix it for activities, but then some other
> dialog would likely hit this still and we would be spinning our wheels for a
> bit trying to cover all cases.
> 
> I think one way to fix might be to basically gut utility_tray, and have some
> app_utility_tray, or some additional forwarder in app_statusbar. If we move
> logic into the app window we may be able to change the element or strategy
> that we're using to listen to events.
> 
> Etienne - Do you have any preferred approach here?

Okay, I found that I failed to understand why we are publishing global-search-request from utility tray instead of appChrome - even while utility tray is not opened. Utility tray should be inactive in this issue. Could you guys tell me? It does not seem intuitive an inactive UI is involved in the process to launch rocketbar. If some day utility is removed we will miss this 'feature' to launch rocketbar.

Comment 14

[Kevin Grandon :kgrandon]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #13)
> Okay, I found that I failed to understand why we are publishing
> global-search-request from utility tray instead of appChrome - even while
> utility tray is not opened. Utility tray should be inactive in this issue.
> Could you guys tell me? It does not seem intuitive an inactive UI is
> involved in the process to launch rocketbar. If some day utility is removed
> we will miss this 'feature' to launch rocketbar.

I believe the problem is that we listen to events on the top-panel, because that covers the rocketbar input a bit for utility tray gestures. Without it we could miss some touch events on rocketbar.

Comment 15

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Kevin Grandon :kgrandon from comment #14)
> (In reply to Alive Kuo [:alive][NEEDINFO!] from comment #13)
> > Okay, I found that I failed to understand why we are publishing
> > global-search-request from utility tray instead of appChrome - even while
> > utility tray is not opened. Utility tray should be inactive in this issue.
> > Could you guys tell me? It does not seem intuitive an inactive UI is
> > involved in the process to launch rocketbar. If some day utility is removed
> > we will miss this 'feature' to launch rocketbar.
> 
> I believe the problem is that we listen to events on the top-panel, because
> that covers the rocketbar input a bit for utility tray gestures. Without it
> we could miss some touch events on rocketbar.

Looks like it is because we embed the rocketbar UI inside statusbar, and statusbar is forwarding touch events to utilityTray. I hope we have chance to refine this architecture in the future.

Back to this issue, simply upgrading the z-index of the action menu works for me. Or either moving the activityMenu inside the appWindow who triggers it, then even the rocketbar shows it will not be strange because rocketbar is behind the menu as well as the app window. What do you think?

Comment 16

[Kevin Grandon :kgrandon]

My assumption was that we wanted users to be able to pull down the utility tray from within an action menu. Maybe that is not a necessary use case though, so if that works, that'd be fine by me.

Comment 17

[GitHub Autolander Bot]

Attachment: [PullReq] KevinGrandon:bug_1113050_action_menu_zindex to mozilla-b2g:master

Comment 18

[Kevin Grandon :kgrandon]

Comment on attachment 8545514 [details] [review]
[PullReq] KevinGrandon:bug_1113050_action_menu_zindex to mozilla-b2g:master

This is a pull request to increase the z-index of action-menu and place it over the gesture-panel as suggested. Please take a look when you have a minute Alive. Thanks!

Comment 19

[Etienne Segonzac (:etienne)]

Not that big of a deal but this will have bad side effects on the "swipe to go home" gesture (if anybody still uses it) :/

Comment 20

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 8545514 [details] [review]
[PullReq] KevinGrandon:bug_1113050_action_menu_zindex to mozilla-b2g:master

Let's see if any regression.

Comment 21

[Kevin Grandon :kgrandon]

Crossing fingers for no regressions: https://github.com/mozilla-b2g/gaia/commit/a057275ae6ad26a65a86a93aa73949a611df6e6f

Comment 23

[Sue]

Attachment: verify_video.MP4

This issue has been verified successfully on Flame 2.2
See attachment:verify_video.MP4
Rate:0/5

Flame 2.2 build:
Gaia-Rev        7c5b27cad370db377b18a742d3f3fdb0070e899f
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/748b20315f75
Build-ID        20150113162504
Version         37.0a2
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150113.194114
FW-Date         Tue Jan 13 19:41:25 EST 2015
Bootloader      L1TC000118D0