Closed Bug 1096704 Opened 7 years ago Closed 7 years ago

[Window Management] Swiping up while edge gesturing causes the user to be stuck on a blank page


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

Gonk (Firefox OS)
Not set


(blocking-b2g:2.1+, b2g-v2.0 unaffected, b2g-v2.1 verified, b2g-v2.2 verified)

2.2 S1 (5dec)
blocking-b2g 2.1+
Tracking Status
b2g-v2.0 --- unaffected
b2g-v2.1 --- verified
b2g-v2.2 --- verified


(Reporter: KTucker, Assigned: etienne)




(Keywords: regression, Whiteboard: [2.1-exploratory-3][systemsfe])


(5 files, 1 obsolete file)

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.

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.

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

Repro frequency: 100%
See attached: video clip, logcat,
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?]
Flags: needinfo?(pbylenga)
Keywords: regression
Whiteboard: [2.1-exploratory-3] → [2.1-exploratory-3][systemsfe]
Flags: needinfo?(pbylenga) → needinfo?(jmitchell)
[Blocking Requested - why for this release]: Regression, broken functionality (blank page), poor UX
blocking-b2g: --- → 2.1?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Etienne, can you take a look here?
Flags: needinfo?(etienne)
QA Contact: ddixon
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
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:

Possible Cause: 

 bug 1069452 - Never take screenshot of closing AppWindow if part of h…
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
broken by  bug 1069452 ? Can you take a look Aus?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell) → needinfo?(aus)
QA Contact: ddixon
Broken functionality.
blocking-b2g: 2.1? → 2.1+
Assignee: nobody → aus
I'll have a look at this asap. Sounds nasty :(

Etienne, any input you have would be appreciated.
Flags: needinfo?(aus)
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 :)
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)
Duplicate of this bug: 1097943
Comment on attachment 8522901 [details] [diff] [review]

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+

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)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Attachment #8522901 - Attachment is obsolete: true
Attachment #8523858 - Flags: review?(aus)
Attachment #8523858 - Flags: review?(alive)
Target Milestone: --- → 2.1 S9 (21Nov)
:ddixon, The patch that was originally posted ( 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)
: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 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+
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
URL for new video listed in Comment 17:
Comment on attachment 8523858 [details] [review]
Github PR against master

Attachment #8523858 - Flags: review?(alive) → review+

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.
Closed: 7 years ago
Resolution: --- → FIXED
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?

Ni on Etienne, I'm also looking into what might be causing the failures.
Flags: needinfo?(etienne)
Resolution: FIXED → ---
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 :)
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.
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.
Attached file PR for relanding
new PR to reland this, carrying the r+
Flags: needinfo?(etienne)
Attachment #8526806 - Flags: review+
Closed: 7 years ago7 years ago
Resolution: --- → FIXED
Please request Gaia v2.1 approval on this when you get a chance.
Flags: needinfo?(etienne)
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?
Keywords: verifyme
Attachment #8526806 - Flags: approval-gaia-v2.1? → approval-gaia-v2.1+
Duane, please verify this issue is fixed once 2.1 has been uplifted.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage-]
Flags: needinfo?(ddixon)
Needs rebasing for v2.1 uplift.
Flags: needinfo?(etienne)
Attached file PR against 2.1
carrying the r+
Flags: needinfo?(etienne)
Attachment #8533826 - Flags: review+
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
QA Whiteboard: [QAnalyst-Triage-] → [QAnalyst-Triage?]
Flags: needinfo?(ddixon) → needinfo?(ktucker)
Keywords: verifyme
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Depends on: 1110630
You need to log in before you can comment on or make changes to this bug.