1147161 - [Windows Management] Rocket Bar / Search Bar is accessible behind Browser / Marketplace long-press contextual menus causing install app pages to open behind the menu

Status: RESOLVED DUPLICATE of bug 1150834

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

Description

[Joshua Mitchell (Inactive)]

Attachment: logcat_20150324_1416.txt

Description:
When you long-press on certain things (example: a link or a picture) a long-press contextual menu comes up. This menu is gray, and dims out the notification bar, and there is no search bar / rocketbar present. When you tap in upper left corner it will still activate the search bar.

User Impact: If the user were then to use the rocketbar and select a search result that will install something from the marketplace - the application details page will open behind the long-press contextual menu (see video) 

Notes: This seems similar to bug 1030433 - where the rocketbar search install page (app details page) comes up behind several other types of screens

Repro Steps:
1) Update a Flame to 20150324010202
2) Open Marketplace
3) Long press on a link or picture to bring up long-press contextual menu
4) Tap the upper left corner to bring up rocketbar
5) Type in 'zombie' (for example) and tap install zombie apocalypse

Actual:
App install / details page opens behind the contextual menu

Expected:
Rocketbar will not be accessible when on a contextual menu
-or-
Transitioning to the app detail / install page will force close the long-press contextual menu

Environmental Variables:
Device: Flame Master (KK - Nightly - Full Flashed - 319mem)
Build ID: 20150324010202
Gaia: efebbafd12fc42ddcd378948b683a51106517660
Gecko: 840cfd5bc971
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 39.0a1 (Master)
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0


Repro frequency: 10/10
See attached: logcat, video: 1030433

Comment 1

[Joshua Mitchell (Inactive)]

This issue also occurs in Flame 2.2 and 2.1  

Contextual menus and rocketbar are not present in 2.0 

Device: Flame 2.2 (KK - Nightly - Full Flash - 319mem)
Build ID: 20150323002504
Gaia: 7f367fc98ffdd183f21d2cdfe20556ab877ece34
Gecko: 3ea0eaeda353
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 37.0 (Master)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Device: Flame 2.1 (KK - Nightly - Full Flash - 319mem)
Build ID: 20150323001203
Gaia: 13c85d57f49b4bfd657ff674f2b530c141c94803
Gecko: aeabf85a622c
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 34.0 (2.1)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Comment 2

[Peter Bylenga [:PBylenga]]

NI on component owner for nomination decision and assignment.

Comment 3

[Hermes Cheng (inactive after July 27, 2015)]

It seems to be another triggerable hidden rocketbar issue just like bug 1140254 and bug 1143142.

Besides, I think the other issue here is that the marketplace does not close "the long-press contextual menu" and transit to the app detail.

Alive, could you take a look?

Comment 4

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

One another rocketbar access issue. Michael or Kevin, I think this one is important enough to track.

Comment 5

[Gregor Wagner [:gwagner]]

Francis, is this a bug or a feature?

Comment 6

[Kevin Grandon :kgrandon]

Thanks for the heads-up. Probably a bug with the event targeting, and not checking if the rocketbar is visible before activation.

Comment 7

[Michael Henretty [:mikehenrty][:mhenretty]]

Let's take a look in triage.

Comment 8

[Gregor Wagner [:gwagner]]

Not a blocker but we should fix it.

Comment 9

[Francis Djabri [:djabber]]

In this case, this is a bug. From the homescreen, I think we should still be able to access the Rocket bar when it is collapsed, because ideally it is meant to remain. But in this case, we're breaking UI conventions by allowing something to be active behind a scrim.

Comment 10

[Hermes Cheng (inactive after July 27, 2015)]

This bug is resolved after bug 1150834 was fixed.
Mark as duplicated, but please correct me if I am wrong.