Closed
Bug 1096704
Opened 10 years ago
Closed 10 years ago
[Window Management] Swiping up while edge gesturing causes the user to be stuck on a blank page
Categories
(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)
Tracking
(blocking-b2g:2.1+, b2g-v2.0 unaffected, b2g-v2.1 verified, b2g-v2.2 verified)
Tracking | Status | |
---|---|---|
b2g-v2.0 | --- | unaffected |
b2g-v2.1 | --- | verified |
b2g-v2.2 | --- | verified |
People
(Reporter: KTucker, Assigned: etienne)
References
()
Details
(Keywords: regression, Whiteboard: [2.1-exploratory-3][systemsfe])
Attachments
(5 files, 1 obsolete file)
378.69 KB,
text/plain
|
Details | |
46 bytes,
text/x-github-pull-request
|
alive
:
review+
aus
:
review+
|
Details | Review |
7.90 KB,
image/png
|
Details | |
46 bytes,
text/x-github-pull-request
|
etienne
:
review+
bajaj
:
approval-gaia-v2.1+
|
Details | Review |
46 bytes,
text/x-github-pull-request
|
etienne
:
review+
|
Details | Review |
Description:
Swiping up while edge gesturing between windows causes the user to be stuck on a blank page. The user will have to restart their device. The home button will vibrate when pressed but will not take the user to the homescreen.
Repro Steps:
1) Updated Flame to Build ID: 20141110001201
2) Tap on the "Settings" icon and then tap on "Browsing Privacy".
3) On the "Browsing Privacy" page, tap on the "Rocketbar", type in pizza and tap the search icon on the keyboard.
4) On the Google browser page that opens up, tap on the "..." and tap on "New window".
5) Edge gesture back to the "Browsing Privacy" page and perform another search for "Pizza" using the "Rocketbar".
6) Edge gesture back and forth between all the open windows. While transitioning between windows, do a quick "Swipe up" with your finger like you were closing a window in card view.
7) Keep performing step 6 until encountering the blank page with the "Rocketbar".
8) Tap the "Home button" on the phone while on the blank page.
Actual:
The user will get stuck on a blank white page that contains only the "Rocketbar". Tapping the home button on the phone will not take the user to the homescreen. They will have to restart their device to recover.
Expected:
The user does not get stuck on a blank page and the user can always get to the homescreen when pressing the "Home" button.
Environmental Variables
Device: Flame 2.1 (319mb)(Kitkat Base)(Shallow Flash)
BuildID: 20141110001201
Gaia: 0ec1925fc37b7c71d129ae44e42516a0cfb013c4
Gecko: 97487a2d1ee6
Version: 34.0 (2.1)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Notes:
Repro frequency: 100%
See attached: video clip, logcat,
Reporter | ||
Comment 1•10 years ago
|
||
This issue does not reproduce on the Flame 2.2 or the Flame 2.0
The user does not get stuck on a blank page when swiping up while edge gesturing between windows.
Flame 2.2
Device: Flame 2.2 Master (319mb)(Kitkat Base)(Shallow Flash)
BuildID: 20141110040206
Gaia: 5f8206bab97cdd7b547cc2c8953cadb2a80a7e11
Gecko: d380166816dd
Version: 36.0a1 (2.2 Master)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
Flame 2.0
Device: Flame 2.0 (319mb)(Kitkat Base)(Shallow Flash)
BuildID: 20141110000204
Gaia: d3e4da377ee448f9c25f908159480e867dfb13f3
Gecko: 7198906837e7
Version: 32.0 (2.0)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-v2.2:
--- → unaffected
Flags: needinfo?(pbylenga)
Keywords: regression
Reporter | ||
Updated•10 years ago
|
status-b2g-v2.0:
--- → unaffected
Reporter | ||
Updated•10 years ago
|
Whiteboard: [2.1-exploratory-3] → [2.1-exploratory-3][systemsfe]
Reporter | ||
Updated•10 years ago
|
Flags: needinfo?(pbylenga) → needinfo?(jmitchell)
Comment 2•10 years ago
|
||
[Blocking Requested - why for this release]: Regression, broken functionality (blank page), poor UX
blocking-b2g: --- → 2.1?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: regressionwindow-wanted
Updated•10 years ago
|
QA Contact: ddixon
Comment 4•10 years ago
|
||
Central Regression Window
Last Working
Device: Flame 2.2
BuildID: 20140926135539
Gaia: e30d373eb5ed0514bce08a3b3d80d71b05a4dc32
Gecko: 16ff803b47a9
Version: 35.0a1 (2.2)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0
First Broken
Device: Flame 2.2
BuildID: 20140926182541
Gaia: 2834baf4c7e34fe6ef335f0469f6d0f593c5922b
Gecko: a5e456511fe9
Gonk:
Version: 35.0a1 (2.2)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0
Last Working Gaia and First Broken Gecko
Issue DOES NOT occur here.
Gaia: e30d373eb5ed0514bce08a3b3d80d71b05a4dc32
Gecko: a5e456511fe9
Last Working Gecko and First Broken Gaia
Issue DOES occur here.
Gaia: 2834baf4c7e34fe6ef335f0469f6d0f593c5922b
Gecko: 16ff803b47a9
Gaia Pushlog:
https://github.com/mozilla-b2g/gaia/compare/e30d373eb5ed0514bce08a3b3d80d71b05a4dc32...2834baf4c7e34fe6ef335f0469f6d0f593c5922b
Possible Cause:
bug 1069452 - Never take screenshot of closing AppWindow if part of h…
Comment 5•10 years ago
|
||
broken by bug 1069452 ? Can you take a look Aus?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell) → needinfo?(aus)
QA Contact: ddixon
Updated•10 years ago
|
Assignee: nobody → aus
Comment 7•10 years ago
|
||
I'll have a look at this asap. Sounds nasty :(
Etienne, any input you have would be appreciated.
Flags: needinfo?(aus)
Assignee | ||
Comment 8•10 years ago
|
||
Interesting...
First: it's possible to expand/collapse the rocketbar while the overlay is displayed on top of a web sheet, we should probably use the touch-blocker div to prevent that.
Then there's the issue that tapping the top left corner will always trigger the rocketbar, even if the currently displayed app is not active. So we're actively looking for edge cases :)
Assignee | ||
Comment 9•10 years ago
|
||
Here's a simple wip.
Will work on tests and check if we should base it on master or be 2.1 only.
Does it fix the issue for everybody?
(the STR are tricky and perf/timing related it seems)
Assignee: aus → etienne
Flags: needinfo?(etienne) → needinfo?(ktucker)
Attachment #8522901 -
Flags: feedback?(aus)
Comment 11•10 years ago
|
||
Comment on attachment 8522901 [details] [diff] [review]
0001-Bug-1096704-Prevent-rocketbar-trigger-during-an-edge.patch
Review of attachment 8522901 [details] [diff] [review]:
-----------------------------------------------------------------
Only one nit, and this patch resolves the issue for me on 2.1. I tried to apply it on 2.2 and unfortunately it doesn't apply cleanly so it will need to be rebased.
::: apps/system/js/rocketbar.js
@@ +272,5 @@
> // but currently the transition sequence is crucial for performance
> var app = AppWindowManager.getActiveApp();
> var afterActivate;
>
> + if (app && !app.isActive()) {
It would be nice to add a comment here explaining this check. :)
Attachment #8522901 -
Flags: feedback?(aus) → feedback+
Comment 12•10 years ago
|
||
Aus,
I am testing the patch "bug-1096704" made for this bug.
I am seeing the same results with AND without the patch being applied in the latest Flame 2.2 build (Full Flash, nightly). Further, I am seeing the same results you have listed in Comment 11. I am confused as to why I am getting the same results on 2.1 and 2.2 with the patch applied. Any suggestions? Thanks.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(aus)
Reporter | ||
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Assignee | ||
Comment 13•10 years ago
|
||
Attachment #8522901 -
Attachment is obsolete: true
Attachment #8523858 -
Flags: review?(aus)
Attachment #8523858 -
Flags: review?(alive)
Updated•10 years ago
|
Target Milestone: --- → 2.1 S9 (21Nov)
Comment 14•10 years ago
|
||
:ddixon, The patch that was originally posted (https://bugzilla.mozilla.org/attachment.cgi?id=8522901&action=edit) only applies on 2.1.
After doing a full flash of the nightly build you will need to apply the patch to gaia 2.1 branch and do 'make reset-gaia'. If you do not, you will still end up using the code in the original nightly build you flashed.
Flags: needinfo?(aus)
Comment 15•10 years ago
|
||
:ddixon, one more thing also, the new Pull Request is based on master so you should be able to flash a full nightly (mozilla central! not aurora!), apply the patch to a working gaia master tree and do make reset-gaia.
Comment 16•10 years ago
|
||
Comment on attachment 8523858 [details] [review]
Github PR against master
Looks great! I'm a little concerned that QA didn't see the issue fixed with the original WIP but it fixed the issue for me... This patch does the trick as well on master on my Flame (v188, 319M, latest gecko+gaia+pull request applied).
Attachment #8523858 -
Flags: review?(aus) → review+
Comment 17•10 years ago
|
||
I applied the patch to the latest Flame 2.2 build (Full Flash, nightly, 319 MB).
1) Applied patch "bug-1096704"
2) Used "make reset-gaia"
3) Restarted my device
Actual Results: Edge gesturing between apps then quickly swiping upwards does not cause the app to freeze or crash. However, an app will sometimes flash a black screen.
Attached video of my results: "edge_swipe_2.2_with_patch.mpeg"
Environmental Variables:
Device: Flame 2.2
Build ID: 20141117040203
Gaia: 268315b482eb6d00d2a496b8b8eac767dfebda60
Gecko: 21b745197618
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 36.0a1 (2.2)
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
Comment 18•10 years ago
|
||
URL for new video listed in Comment 17: http://youtu.be/ygG4z_r8A7o
Comment 19•10 years ago
|
||
Comment on attachment 8523858 [details] [review]
Github PR against master
LGTM
Attachment #8523858 -
Flags: review?(alive) → review+
Assignee | ||
Comment 20•10 years ago
|
||
https://github.com/mozilla-b2g/gaia/commit/118f64988eeb0b5d90c61f31810dde5dcd1b0343
The video looks promising (except for the performance but that's unrelated to this bug), we should make sure this gets dully verified once it reaches 2.1.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Comment 21•10 years ago
|
||
Backed out for causing integration test failures like "TEST-UNEXPECTED-FAIL | apps/system/test/marionette/global_search_test.js | Global search > Triggering the search from the hot corner". Perhaps this conflicted with something after the try run?
https://tbpl.mozilla.org/php/getParsedLog.php?id=52863805&tree=B2g-Inbound#error0
https://github.com/mozilla-b2g/gaia/commit/d7a0a2b6803d3ac626defc77441ae87f2f580e30
Ni on Etienne, I'm also looking into what might be causing the failures.
Status: RESOLVED → REOPENED
Flags: needinfo?(etienne)
Resolution: FIXED → ---
Comment 22•10 years ago
|
||
Assignee | ||
Comment 23•10 years ago
|
||
Opened a new pull request, I think this was an rebase issue with the landing of the last browser api change fixes, but I'll triple-check :)
https://github.com/mozilla-b2g/gaia/pull/26248
Comment 24•10 years ago
|
||
Looks like the try runs are passing in both of our PRs. This is weird, but I've re-triggered each a few times. If they end up passing on your run, but fail on b-i, this means we might have some code discrepancy on m-c vs b-i.
Comment 25•10 years ago
|
||
It seems that both of our try runs are green, so I guess you should go ahead and re-land your PR and pay attention to the tree. If it fails I guess there must be some discrepancy between b-i and m-c. I'd land it now, but I'm not going to be around to watch the tree. Sorry about the backout if it was improper.
Assignee | ||
Comment 26•10 years ago
|
||
new PR to reland this, carrying the r+
Flags: needinfo?(etienne)
Attachment #8526806 -
Flags: review+
Assignee | ||
Comment 27•10 years ago
|
||
Status: REOPENED → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → FIXED
Comment 28•10 years ago
|
||
Please request Gaia v2.1 approval on this when you get a chance.
Flags: needinfo?(etienne)
Assignee | ||
Comment 29•10 years ago
|
||
Comment on attachment 8526806 [details] [review]
PR for relanding
[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): the app overlay for edge gestures (I think bug 992081 originally) and the global search (bug 1042083).
[User impact] if declined: while the overlay is displayed it is actually possible to act on the app/on the rocketbar. This itself is pretty minor, but it does expose us to a bunch of rocketbar edge cases where we break pretty badly and the user is stuck until reboot.
[Testing completed]: Rocket bar and edge gestures typical tests + an integration test covering the main race condition.
[Risk to taking this patch] (and alternatives if risky): low-ish, a simple and well tested change is made to a core part of the system app.
[String changes made]: none
Flags: needinfo?(etienne)
Attachment #8526806 -
Flags: approval-gaia-v2.1?
Updated•10 years ago
|
Attachment #8526806 -
Flags: approval-gaia-v2.1? → approval-gaia-v2.1+
Reporter | ||
Comment 30•10 years ago
|
||
Duane, please verify this issue is fixed once 2.1 has been uplifted.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage-]
Flags: needinfo?(ddixon)
Comment 31•10 years ago
|
||
Needs rebasing for v2.1 uplift.
Flags: needinfo?(etienne)
Keywords: branch-patch-needed
Assignee | ||
Comment 32•10 years ago
|
||
carrying the r+
Flags: needinfo?(etienne)
Attachment #8533826 -
Flags: review+
Comment 33•10 years ago
|
||
Keywords: branch-patch-needed
Target Milestone: 2.1 S9 (21Nov) → 2.2 S1 (5dec)
Comment 34•10 years ago
|
||
Issue is verified fixed in latest Flame 2.1, 2.2 builds (Full flash, nightly, 319 MB memory).
Actual Results: Edge gesturing between apps and quickly swiping upwards does not cause a unresponsive white screen.
Device: Flame 2.2
BuildID: 20141211040208
Gaia: 1a956437210d2b16988d2ddbf40c9a38d8474435
Gecko: d92db71d4e67
Gonk: 263b5f41f7733c5577fb101eb4dc8ac5c11cfa8d
Version: 37.0a1 (2.2)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
Device: Flame 2.1
BuildID: 20141211001204
Gaia: 97873dca486abf4162a3345e71b375806937bdec
Gecko: 9faa165ac85d
Gonk: 263b5f41f7733c5577fb101eb4dc8ac5c11cfa8d
Version: 34.0 (2.1)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage-] → [QAnalyst-Triage?]
Flags: needinfo?(ddixon) → needinfo?(ktucker)
Keywords: verifyme
Reporter | ||
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
You need to log in
before you can comment on or make changes to this bug.
Description
•