Closed Bug 1021857 Opened 5 years ago Closed 5 years ago
.0][Everything .me ] User can get e .me to appear over the dialer when on a call
66.58 KB, text/plain
846.59 KB, image/png
46 bytes, text/x-github-pull-request
|Details | Review|
755.86 KB, image/png
383.80 KB, image/png
6.57 KB, patch
|Details | Diff | Splinter Review|
868.92 KB, video/mp4
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: 22.214.171.124 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+
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?
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.
This will continue to do the right thing. There are other visual glitches though that we'll address in other bugs.
Whiteboard: [2.0-FL-bug-bash][systemsfe] → [2.0-FL-bug-bash][systemsfe][p=3]
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
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+
Status: REOPENED → RESOLVED
Closed: 5 years ago → 5 years ago
Resolution: --- → FIXED
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.
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
You need to log in before you can comment on or make changes to this bug.