Closed Bug 833454 Opened 11 years ago Closed 11 years ago

cards view gets stuck during activity transition

Categories

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

Product:
Firefox OS Graveyard
Component:
Gaia::System
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(blocking-b2g:tef+, b2g18 fixed, b2g18-v1.0.0 fixed, b2g18-v1.0.1 verified)

Status:
VERIFIED FIXED
Project Flags:
blocking-b2g tef+
Tracking Flags:
Tracking Status
b2g18 --- fixed
b2g18-v1.0.0 --- fixed
b2g18-v1.0.1 --- verified

People

(Reporter: nhirata, Assigned: alive)

References

Details

(Keywords: smoketest)

Attachments

(2 files)

screenshot
132.42 KB, image/png
Details
https://github.com/mozilla-b2g/gaia/pull/7844
86 bytes, text/html
timdream
: review+
Details
Attached image screenshot — 
## Environment :
Gecko  http://hg.mozilla.org/releases/mozilla-b2g18/rev/0e43266ca3c6
Gaia   1890022f3ca36108621a832f31ac5df8bf89a22e
BuildID 20130122070203
Version 18.0
Unagi

## Repro :
1. set to PT-BR
2. go to settings -> select wifi
3. select the home button
4. go to gallery
5. select a video
6. select share
7. allow for bluetooth to be turned on
8. allow for setting up blue tooth

## Expected :
1. going to the settings for blue tooth

## Actual :
1. settings is stuck in task manager.



## Note :
01-22 10:42:41.773: E/GeckoConsole(1396): [JavaScript Error: "NS_ERROR_FAILURE: Failure arg 0 [nsIDOMRequestService.fireSuccess]" {file: "jar:file:///system/b2g/omni.ja!/components/ActivityProxy.js" line: 79}]
Hrm doesn't seem to repro all the time.  I think Gallery has to be shut down, and the settings has to be running in the background.

Also please ignore the note section.  that logcat doesn't have to do with this particular bug I believe.
I can reproduce this. I'm using the english locale.

I did it with the settings app running. Obviously gallery is running too, since I just started a share from there.  It wouldn't work if I was already paired with my laptop. But if I unpaired, that is when the activity would be triggered to switch to settings, I guess.

My screenshot looks just like Naoki's.  A little bit of the gallery app on the left, and the settings app in the middle. Astonishingly, tapping on the miniature settings app page turns bluetooth on and off.  And I can also pan the homescreen underneath the settings app.

Sleeping the phone and waking it does not cure the condition.  Launching a new app from the partially-visible homescreen does make it go away.

Cc'ing everyone who has touched the window manager or cards view recently.

Nominating this as a tef blocker.  If the transition animation can break like this for the gallery->settings animation, who knows what other times it will break.  Even if this particular case is rare, we need to understand why it is happening.  

Triage: please view the screenshot before deciding on this one.
blocking-b2g: --- → tef?
I cannot reproduce(Don't know what step 7.8 means). And this seems like an old issue about cards view stuck which isn't reproduced recently.
I find another problem here:
when you are in activity selector, go to cards view and click another app, the app list would be there upon the new app.
I cannot reproduce this either :-/
Here are my steps to reproduce:

1) Reboot phone
2) Launch Settings. Tap on Bluetooth. Confirm that Bluetooth is on, but no device is paired
3) Launch Gallery.
4) Tap on a photo (or video)
5) Tap the Share button
6) Select Bluetooth Transfer
7) When asked "would you like to pair a device now?" click "Pair Device"
8) You may see the bug now. If not, note that logcat has a warning that the share activity was cancelled. 
9) If you did not see the bug in step 8, wwitch back to gallery by pressing and holding Home and using cards view, then repeat steps 5 through 7.  Usually, I see the bug described here or the screen flashes and I remain at the gallery with no switch to settings at all.
I just flashed https://pvtbuilds.mozilla.org/pub/mozilla.org/b2g/nightly/mozilla-b2g18-unagi/latest/unagi.zip (23-Jan-2013 11:46) and have confirmed that I can reproduce this following the steps above.
We would take a patch for this.
blocking-b2g: tef? → -
tracking-b2g18: --- → +
See also bug 834550
See also bug 834472
Okay, this bug has reappeared twice in smoketests now.  I'm adding smoketest to the keywords.

Because it came up twice in the recent smoketests, I'm renominating it as tef+. Maybe leo or shira would be better, but I don't know which one is which. We need to get it fixed ASAP, since it is happening more often now.

This has to do with the cards view transition for activities that are not inline. I've got no idea what is going wrong, but I think we've got the right set of people cc'ed on this bug.

Who has free cycles to look at the window manager or cards view modules?
blocking-b2g: - → tef?
Keywords: smoketest
Changing the summary line to reflect that is is not gallery/settings specific, and changing the component from gaia:gallery to gaia:system.

One of the duped bugs reproduced this just by transitioning back and forth between gallery and camera.  This bug did it for the transition from bluetooth app (itself lauched by activity) to settings app.
Component: Gaia::Gallery → Gaia::System
QA Contact: jhammink
Summary: [gallery]Settings stuck in Task Manager Mode when trying to share a video from gallery using bluetooth → cards view gets stuck during activity transition
I totally forgot I written this bug... thanks djf!

This bug occurs more often in the latest builds.

1. go to settings -> help
2. press the support button
3. hit home
4. go back to settings
5. press the support button again.

Basically when you call another app that's open through a webactivity I think is when you hit it.
I will take a look tomorrow.
I can reproduce now, but I think It's not about activity, just 'the transition between 2 apps' are broken by unknown reason.
The classes to control transition is correctly added to the appWindow, but there's no transtion happening after that.
And the transition doesn't fail every time.
Smells like:
1. Race condition in window manager
2. transition issue in gecko

I fix a race condition that an appWindow has opening-switching and opening-card at the same time but doesn't fix this issue.
(In reply to Alive Kuo [:alive] from comment #19)
> And the transition doesn't fail every time.
> Smells like:
> 1. Race condition in window manager
Hmm, not sure if its race condition because it can be so consistently reproduced in bug 834875
(In reply to Inder from comment #20)
> (In reply to Alive Kuo [:alive] from comment #19)
> > And the transition doesn't fail every time.
> > Smells like:
> > 1. Race condition in window manager
> Hmm, not sure if its race condition because it can be so consistently
> reproduced in bug 834875

What I see is you must repeat several times to switch between gallery and camera to get this happened.
Assignee: nobody → alive
blocking-b2g: tef? → tef+
tracking-b2g18: + → ---
> 
> What I see is you must repeat several times to switch between gallery and
> camera to get this happened.

Alive, what I noticed that it always happen in 2nd switch to gallery from camera app. See STR in bug 834875. This might help you in figuring out the issue.
I just confirmed that this should be a race condition in window manager. Might exist before long time ago :(
Patch coming.
Patch proposal:

The app switching in window manager is not a pure state machine.
The class `opening-card` may be added after `closing-card` transition is over, because the `opening-card` add relies on an API callback.

However, if that happens, we should avoid doing transition *AGAIN* because it is too late. The closed app is already moved to left of the screen, and the opening app is supposed to do the `opening` transition instead of `opening-card` which brings it from right side of the screen.

David, could you review this one? Because you have addressed and helped to investigate some parts of this issue. If you don't want to review, please assign the reviewer to timdream. Thanks!

Note:
We should re-visit and review the app transition flow after v1. It's not a pure state machine. This patch is just a minimal workaround. I hope you could accept.
Attachment #707558 - Flags: review?(dflanagan)
Comment on attachment 707558 [details]
https://github.com/mozilla-b2g/gaia/pull/7844

Just talked to Tim so reset the reviewer but welcome David if you want to review.
Attachment #707558 - Flags: review?(dflanagan) → review?(timdream)
I commented on github, but am very unfamiliar with the code being modified so I'd prefer to leave the formal review to Tim.
Comment on attachment 707558 [details]
https://github.com/mozilla-b2g/gaia/pull/7844

With the offline discussion, I am told the specific situation only took place when the painting takes more time than the closing card transition, which is 0.3 sec.

(In reply to Alive Kuo [:alive] from comment #25)
> We should re-visit and review the app transition flow after v1. It's not a
> pure state machine. This patch is just a minimal workaround.

Yeah I agree. I am not sure I understand you by not a "pure" state machine though. This is definitely under the post-v1 agenda.
Attachment #707558 - Flags: review?(timdream) → review+
Marking status-b2g18 and status-b2g18-v1.0.0 as affected, please update the status to fixed once this is verified landed on v1-train and v1.0.0
status-b2g18: --- → affected
status-b2g18-v1.0.0: --- → affected
Status: NEW → RESOLVED
Closed: 11 years ago
status-b2g18: affected → fixed
status-b2g18-v1.0.0: affected → fixed
Resolution: --- → FIXED
I had this occur once in 1/31/2013, but I can't seem to repro.

Filed bug 836843 for blackness on start of a closed app.
Ah I figured it out.  Pull request wasn't in... that's why it still occured in today's build.  1/31.  Will have to check tomorrow or build my own.
Issue of the Bluetooth card getting stuck when moving from gallery to the Bluetooth menu no longer reproduces on the Unagi device.

Build ID: 20130313070202
Kernel Date: Dec 5
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/e74dafa6b2d9
Gaia: b34e726147f8e671ad8c538b50900ccfbffcb084
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: