Closed Bug 1021857 Opened 5 years ago Closed 5 years ago

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

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(blocking-b2g:2.0+, b2g-v1.3 unaffected, b2g-v1.3T unaffected, b2g-v1.4 unaffected, b2g-v2.0 verified, b2g-v2.1 verified)

VERIFIED FIXED
2.0 S4 (20june)
blocking-b2g 2.0+
Tracking Status
b2g-v1.3 --- unaffected
b2g-v1.3T --- unaffected
b2g-v1.4 --- unaffected
b2g-v2.0 --- verified
b2g-v2.1 --- verified

People

(Reporter: ekramer, Assigned: aus)

References

()

Details

(Whiteboard: [2.0-FL-bug-bash][systemsfe][p=3])

Attachments

(7 files)

Attached file 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
No longer blocks: rocketbar-search-mvp
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1017776
Reopening to track a VH specific fix.
blocking-b2g: --- → 2.0+
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking+]
Blocks: 1015336
No longer blocks: vertical-homescreen
Whiteboard: [2.0-FL-bug-bash] → [2.0-FL-bug-bash][systemsfe]
Component: Gaia::Everything.me → Gaia::System::Window Mgmt
Going to have a look at this.
Assignee: nobody → aus
Status: REOPENED → ASSIGNED
Target Milestone: --- → 2.0 S4 (20june)
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.
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.
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?
Flags: needinfo?(firefoxos-ux-bugzilla)
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. :)
Flagging Francis on comment #7. Reassign as necessary.
Flags: needinfo?(firefoxos-ux-bugzilla) → needinfo?(fdjabri)
Attachment #8441997 - Flags: review?(alive) → review+
(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.
Flags: needinfo?(fdjabri)
This will continue to do the right thing. There are other visual glitches though that we'll address in other bugs.
Commit (master): https://github.com/mozilla-b2g/gaia/commit/f2b7236f28d528cd2a12691fba004e1a2afa929d

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

Fixed!
Status: ASSIGNED → RESOLVED
Closed: 5 years ago5 years ago
Resolution: --- → FIXED
Whiteboard: [2.0-FL-bug-bash][systemsfe] → [2.0-FL-bug-bash][systemsfe][p=3]
Duplicate of this bug: 1030980
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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attached patch bug1021857.patchSplinter Review
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.
Attachment #8447898 - Flags: review?(kgrandon)
Comment on attachment 8447898 [details] [diff] [review]
bug1021857.patch

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

Looks fine to me, thanks!
Attachment #8447898 - Flags: review?(kgrandon) → review+
This is a sad workaround. The right thing seems to be demote searchWindow zindex to below attentionScreen always.
(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.
Attached video 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
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.