1021857 - [B2G][2.0][Everything.me ] User can get e.me to appear over the dialer when on a call

Status: VERIFIED FIXED

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

Description

[Eric Kramer [:Kramer]]

Attachment: e.me_dialer_overlap

Description:
E.me can be made to appear over the dialer when a call is being made. The user can also bring up the keyboard while in this state. 


Repro Steps:
1) Update a Flame to 20140605040202
2) Make a call
3) While the Flame is in a call state press the home button
4) Tap on the e.me / rocketbar
5) Tap on the blue call bar at the top of the screen

Additional Steps:
6) Tap on the e.me bar again while it's over the call screen / dialer.

Actual:
Users will see the e.me overlapping the call screen / dialer. If user tapped the e.me they will also see the keyboard. 

Expected:
The e.me does not appear over the call screen. 

Environmental Variables:
Device: Flame 2.0
Build ID: 20140605040202
Gaia: d2cfef555dabab415085e548ed44c48a99be5c32
Gecko: 51b428be6213
Version: 32.0a1 (2.0) 
Firmware Version: v10G-2


User Agent: 
Gecko / 32.0
Firefox / 32.0
IP: 50.149.104.75


Repro frequency: (100%)
See attached: (screenshot, video clip, logcat)


======================================================

This issue does repro on Open_C 2.0

Environmental Variables:
Device: Open_C 2.0
Build ID: 20140605040202
Gaia: d2cfef555dabab415085e548ed44c48a99be5c32
Gecko: 51b428be6213
Version: 32.0a1 (2.0) 
Firmware Version: P821A10V1.0.0B06_LOG_DL

Comment 1

[Eric Kramer [:Kramer]]

Attachment: e.me overlapping the dialer

Comment 3

[Jason Smith [:jsmith]]

Reopening to track a VH specific fix.

Comment 4

[Aus Lacroix [:aus]]

Going to have a look at this.

Comment 5

[Aus Lacroix [:aus]]

As per alive: you don't need to make a call. Use alarm or uitest->window.open->attentionscreen

I'll come up with some alternate STR for people without the ability to make calls.

Comment 6

[Aus Lacroix [:aus]]

Alternate STR:

1. Open Alarm App, set alarm for 1 minute from now.
2. Wait for Alarm to go off.
3. Tap home button, go to homescreen.
4. Tap rocketbar.
5. Select alarm attentionscreen.

Expected: Alarm app shows by itself.

Actual: Rocketbar is still displayed on top of the alarm app.

Comment 7

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

Aftering thinking more, I think we need to confirm:
(1) Is attention screen always on top of other UI, inclusing rocketbar?
(2) If (1) is yes, do we have a good way to invoke rocketbar while attention screen is opened?

Comment 8

[Aus Lacroix [:aus]]

The proposed fix here is to change the z-index of the AttentionScreen when it is shown in an expanded state outside of the status bar.

This will require also updating the z-index of the keyboard to this same level when the AttentionScreen is shown.

I need to verify with UX that this is OK but it solves the problem very well and will ensure that the AttentionScreen really gets the users full attention when in an expanded state. :)

Comment 9

[Aus Lacroix [:aus]]

Attachment: Pull Request - Make AttentionScreen top-most when shown in expanded state

Comment 10

[Stephany Wilkes]

Flagging Francis on comment #7. Reassign as necessary.

Comment 11

[Francis Djabri [:djabber]]

(In reply to Alive Kuo [:alive][NEEDINFO!][OOO from 6/23 until 6/30] from comment #7)
> Aftering thinking more, I think we need to confirm:
> (1) Is attention screen always on top of other UI, inclusing rocketbar?
> (2) If (1) is yes, do we have a good way to invoke rocketbar while attention
> screen is opened?

I would say:

1) Yes
2) But the search field should still be visible on home screen when an attention screen is in view. If the user selects the search field the search should function normally. 

So in other words it appears as if the attention screen pushes the search field down so that it is still visible. This is how it works in 1.4 and we should retain this.

Comment 12

[Francis Djabri [:djabber]]

Attachment: 1.4 home screen with attention screen showing search field still visible

Comment 13

[Francis Djabri [:djabber]]

Attachment: 1.4 search view with attention screen showing search field still visible

Comment 14

[Aus Lacroix [:aus]]

This will continue to do the right thing. There are other visual glitches though that we'll address in other bugs.

Comment 15

[Aus Lacroix [:aus]]

Commit (master): https://github.com/mozilla-b2g/gaia/commit/f2b7236f28d528cd2a12691fba004e1a2afa929d

Commit (v2.0): https://github.com/mozilla-b2g/gaia/commit/27f07f479e696af304d52e5fdd654317baa8c17d

Fixed!

Comment 17

[Doug Sherk (:drs) (inactive)]

Backed out for causing bug 1030980 and not fixing the original issue (I was still able to repro it).

master: https://github.com/mozilla-b2g/gaia/commit/38a367ba17e8ce3f2a44884c584448f977a81eaf
v2.0: https://github.com/mozilla-b2g/gaia/commit/9b324279fb2225154a50748cb83aa925de4fd11e

Comment 18

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Attachment: bug1021857.patch

That's a tricky z-indexes issues because of where the rocketbar lives.

It would be a nice to have, but it may require playing with z-indexes and moving things into the system app dom which may create other regressions. Let's fix that properly in 2.1, and for now let's just make sure this situation can not be triggered (this is an edge case anyway).

The current patch close the rocketbar search results when an attentionscreen pops up, and restore the previous attention screen if the user try to access the search while there is an attention screen.

Comment 19

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

https://tbpl.mozilla.org/?tree=Gaia-Try&rev=1344652389651a6c2dd0304e2627530fc03b64e4

Comment 20

[Kevin Grandon :kgrandon]

Comment on attachment 8447898 [details] [diff] [review]
bug1021857.patch

Review of attachment 8447898 [details] [diff] [review]:
-----------------------------------------------------------------

Looks fine to me, thanks!

Comment 21

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

https://github.com/mozilla-b2g/gaia/commit/92913fa6c4ea913d0fad92695aade9b0d9d8ca1b

Comment 22

[Ryan VanderMeulen [:RyanVM]]

v2.0: https://github.com/mozilla-b2g/gaia/commit/92141388f9bbeb603b5125d5e7d5f6afb90e06c6

Comment 23

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

This is a sad workaround. The right thing seems to be demote searchWindow zindex to below attentionScreen always.

Comment 24

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

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #23)
> This is a sad workaround. The right thing seems to be demote searchWindow
> zindex to below attentionScreen always.

BTW, I will fix it in bug 927862.

Comment 25

[Lancy(Leave from Mozilla)]

Attachment: Verify_Video_Flame.MP4

This issue has been verified successfully on Flame 2.0 & 2.1.
See attachment: Verify_Video_Flame.MP4
Reproducing rate: 0/10

Flame v2.0 version:
Gaia-Rev        8d1e868864c8a8f1e037685f0656d1da70d08c06
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/c756bd8bf3c3
Build-ID        20141202000201
Version         32.0

Flame v2.1 version:
Gaia-Rev        ccb49abe412c978a4045f0c75abff534372716c4
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/18fb67530b22
Build-ID        20141202001201
Version         34.0