Closed Bug 908381 Opened 6 years ago Closed 6 years ago
.me freezes the phone for ~30sec
Seen on unagi with current trunk. STR: reset-gaia type 'skyfall' into e.me searchbox and hit enter. unseclect remember when permission prompt shows up and click yes (usually the search results are here by now) go back to homescreen type 'skyfall' again in e.me searchbox and hit enter. no results are shown and hitting the home button doesn't do anything. Phone is frozen for around 30 sec. I usually can reproduce this after 2-3 repetitions. It doesn't reproduce with every try.
I have to check if this is also reproducible on b2g18.
Seems like a trunk only problem.
blocking-b2g: leo? → koi?
Ok this seems like a compositor problem. The parent profile: http://people.mozilla.com/~bgirard/cleopatra/#report=43897a163a32e5b98f496e162232460e1772fb46 And the child (homescreen) profile: http://people.mozilla.com/~bgirard/cleopatra/#report=4c1c8c254691a529af72eaad3da633c47ed95c1a
Component: Geolocation → Graphics: Layers
Summary: B2G: Using geolocation within e.me freezes the phone for ~30sec → B2G: E.me freezes the phone for ~30sec
A debug build crashes with the stack in bug 903340. Seems to be related.
Still a problem?
blocking-b2g: koi? → koi+
I was not able to reproduce this issue neither on 1.2 nor 1.3 most resent builds. Phone does not freeze after performing a search in E.me. Build ID: 20130923040214 Gecko: http://hg.mozilla.org/mozilla-central/rev/f97307cb4c95 Gaia: 3408cc3f6b190c8cd31832fbb8cd2ae571041f29 Platform Version: 27.0a1 Build ID: 20130922004001 Gecko: http://hg.mozilla.org/releases/mozilla-aurora/rev/63a505ec015c Gaia: 37866768b8abda56d089c8fe96ec5298fc1df696 Platform Version: 26.0a2
Works for me per comment 6
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
This is reproducing again on aurora because the changes for e.me were backed out.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(In reply to Teodosia Pop from comment #8) > This is reproducing again on aurora because the changes for e.me were backed > out. Can someone else confirm this?
I was not able to reproduce the issue on Aurora. There were situations where search results would not appear (about 40% of the time), but my phone never froze. Environmental variables below: Buri v 1.2 Mozilla RIL Build ID: 20131017004001 Gecko: http://hg.mozilla.org/releases/mozilla-aurora/rev/7ca5d1e81d37 Gaia: dbcc171eae6b4d9d168a48291d5ea54c7580561a Platform Version: 26.0a2
QA Contact: mdavydova → nkhristoforov
Teodosia - I need more information on you how reproduced this bug. Can you provide clear STR used? Was it over wifi? Was it over data? What build did you use?
Prerequisites: Connect to wi-fi. Steps to reproduce: 1. Restart b2g. 2. Tap the search field for e.me app in the homescreen. 3. Search for something ("twitter"). 4. Wait for the results. Expected: The results are displayed. Actual: Most of the time the loading spinner is displayed and never stops loading and the results are never shown. This is failing in our automated tests. We use a 30 sec wait there and it's timing out often. Build information: Gecko http://hg.mozilla.org/releases/mozilla-aurora/rev/7ca5d1e81d37 Gaia dbcc171eae6b4d9d168a48291d5ea54c7580561a BuildID 20131017004001 Version 26.0a2 I will attach the log file and a screen shot. I first reopened bug 899984 since the issue was the same, but you suggested to open this one.
What device did you use to test?
I used an Inari.
Okay. I can reproduce this on Mozilla Guest wifi on a Leo 1.2 build from 10/17/2013.
(In reply to Jason Smith [:jsmith] from comment #17) > Okay. I can reproduce this on Mozilla Guest wifi on a Leo 1.2 build from > 10/17/2013. Actually wait - I'm not right here. I can reproduce a failure where I'm not getting results, but the phone isn't frozen. Now that I re-read this bug - it's talking about the phone freezing, not the failure to find results. I'll open a separate bug for this.
Status: REOPENED → RESOLVED
Closed: 6 years ago → 6 years ago
Resolution: --- → WORKSFORME
Filed bug 928520 to track this.
You need to log in before you can comment on or make changes to this bug.