66.58 KB, text/plain
846.59 KB, image/png
46 bytes, text/x-github-pull-request
|Details | Review | Splinter Review|
755.86 KB, image/png
383.80 KB, image/png
6.57 KB, patch
|Details | Diff | Splinter Review|
868.92 KB, video/mp4
Created attachment 8435964 [details] 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: 188.8.131.52 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: 946452
Status: NEW → RESOLVED
Last Resolved: 4 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. :)
Created attachment 8441997 [details] [review] Pull Request - Make AttentionScreen top-most when shown in expanded state
Attachment #8441997 - Flags: review?(alive)
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.
Created attachment 8442989 [details] 1.4 home screen with attention screen showing search field still visible
Created attachment 8442990 [details] 1.4 search view with attention screen showing search field still visible
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
Last Resolved: 4 years ago → 4 years ago
status-b2g-v1.3: --- → unaffected
status-b2g-v1.3T: --- → unaffected
status-b2g-v1.4: --- → unaffected
status-b2g-v2.0: --- → fixed
status-b2g-v2.1: --- → fixed
Resolution: --- → FIXED
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
Status: RESOLVED → REOPENED
status-b2g-v2.0: fixed → affected
status-b2g-v2.1: fixed → affected
Resolution: FIXED → ---
Created attachment 8447898 [details] [diff] [review] 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.
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
Last Resolved: 4 years ago → 4 years ago
Resolution: --- → FIXED
status-b2g-v2.0: affected → 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.
Created attachment 8531468 [details] 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-b2g-v2.0: fixed → verified
status-b2g-v2.1: fixed → verified
You need to log in before you can comment on or make changes to this bug.