Closed Bug 803430 Opened 12 years ago Closed 12 years ago

Attempt to close the app before opening transition completes will take focus away from homescreen

Categories

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

ARM
Gonk (Firefox OS)
defect

Tracking

(blocking-basecamp:+)

VERIFIED FIXED
blocking-basecamp +

People

(Reporter: mossop, Assigned: timdream)

References

Details

(Keywords: b2g-testdriver, unagi)

Attachments

(2 files)

I was panning back and forth a little on the home screen when it hung, I can lock/unlock the device but the homescreen itself just hung and I couldn't do anything except restart the phone.
blocking-basecamp: --- → ?
This is clearly a serious bug but we really need steps to reproduce, setting qawanted
Keywords: qawanted
hi Dave, which device is this? unagi or otoro?
Flags: needinfo?(dtownsend+bugmail)
possibly OOM due to bug 795179? Would it be possible to get a logcat?
(In reply to Naoki Hirata :nhirata from comment #2) > hi Dave, which device is this? unagi or otoro? Status whiteboard says unagi!
Flags: needinfo?(dtownsend+bugmail)
I would still like a logcat if possible please; I cannot reproduce this bug as it stands on today's build.
Flags: needinfo?(dtownsend+bugmail)
OS: Windows 7 → Gonk
Hardware: x86_64 → ARM
Hangs are *not* evidence of OOM. Most likely this is a focus bug.
Severity: normal → critical
blocking-basecamp: ? → +
Priority: -- → P1
Attached file logcat (deleted) —
Managed to hit this again, opened E-mail (which is broken for me), then I think I went to the home screen, opened task manager and swiped closed E-mail, then panned around the homescreen and it died again. Attached is the full logcat of it. My phone is sat in that state now if anyone wants to stop by to take a look.
Flags: needinfo?(dtownsend+bugmail)
Can't reproduce on Otoro. My hunch is that this is likely one of those bugs where a phone has gone into a "bad state" possibly, which means getting steps to reproduce might be tough. I'm wondering if going with debugging what has happened with the existing phone would be a better strategy. What debugging options do we have with a phone that ends up in a state such as this bug?
Flags: needinfo?(jones.chris.g)
Someone who knows our input-event code needs to attach with gdb and see where events are going.
Flags: needinfo?(jones.chris.g)
(In reply to Chris Jones [:cjones] [:warhammer] from comment #9) > Someone who knows our input-event code needs to attach with gdb and see > where events are going. Do you know who specifically knows the input event code?
Yes, but that depends on location and time of day.
I was able to see some slowness in responsiveness by 1) launching the email app 2) then longtapping home/killing the app without going to the homescreen 3) pan the homescreen 4) repeat 1 ~ 3 a couple of times Eventually I do regain the response. I haven't seen a complete lack of response as reported. Still working on figuring out clear STRs...
Please note these might not be related though, probably would be good to be aware of the follow bugs: bug 804884, bug 804899/bug 804086
I found a STR and not sure is for this case 1. make sure there is no network connection 2. Go to the homescreen (the page with marketplace) 3. Launch the marketplace app 4. You will see the warning page and then press the Back button 5. Repeat 3. and 4. steps 6. And now you will back to homescreen, then try to swipe left or right on screen Homescreen will react very slowly now..
Priority: P1 → --
Priority: -- → P2
I've hit this, but only once. Had to restart to unhang.
I can reproduce this fairly easily using the steps in comment 12. The task tray remains responsive. If I open the tray and launch the settings app, then everything goes back to normal. This feels like a gaia bug in focus or activation handling.
Tim, can you grab this or find someone to take it? This bug is reproduced by closing an "opening" app before window_manager.js thinks that it's fully loaded. I think we end up either blur()ing or setVisible(false)ing the homescreen, but we don't notice that the opening app has been closed, so we never restore focus/visibility back to the homescreen.
Assignee: 21 → timdream+bugs
(In reply to Chris Jones [:cjones] [:warhammer] from comment #17) > Tim, can you grab this or find someone to take it? > > This bug is reproduced by closing an "opening" app before window_manager.js > thinks that it's fully loaded. I think we end up either blur()ing or > setVisible(false)ing the homescreen, but we don't notice that the opening > app has been closed, so we never restore focus/visibility back to the > homescreen. Yeah. One would need to open the app and try to close the app before the 500ms transition finishes to trigger this bug. But it's a bug. Will deliver a fix today.
Summary: Homescreen completely stopped responding → Attempt to close the app before opening transition completes will take focus away from homescreen
https://github.com/mozilla-b2g/gaia/pull/6080 I would consider this is a regression caused by bug 801306, so Vivien would you review it? Thanks.
Attachment #676491 - Flags: review?(21)
Tim, can you check out the zoom in/zoom out transition animation of the browser app with a website open? It looks all weird. The content reflows during the zoom I think. Do you see that with a trunk build?
(In reply to Andreas Gal :gal from comment #20) > Tim, can you check out the zoom in/zoom out transition animation of the > browser app with a website open? It looks all weird. The content reflows > during the zoom I think. Do you see that with a trunk build? Yes, that happen to all OOP frames, just like bug 792351. I am not sure they are the same bug or different ones.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Tested with both Naoki's and John Shih's Esses-T-R and I'm not seeing a any panning problems on homescreen. WFM on 11/14/12 nightly on unagi.
Status: RESOLVED → VERIFIED
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: