Closed Bug 1039445 Opened 10 years ago Closed 10 years ago

[MTBF] homescreen not responding

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.0+, b2g-v2.0 fixed, b2g-v2.1 fixed)

RESOLVED FIXED
2.0 S6 (18july)
blocking-b2g 2.0+
Tracking Status
b2g-v2.0 --- fixed
b2g-v2.1 --- fixed

People

(Reporter: pyang, Assigned: etienne)

References

Details

(Whiteboard: [systemsfe])

Attachments

(4 files)

Attached image photo 1.JPG
Device: flame
Memory: 273MB
Gaia      2c6c413ed729d465c52d6c2d5d458e2eee79e956
Gecko     https://hg.mozilla.org/releases/mozilla-aurora/rev/d32649a24965
BuildID   20140715000201
Version   32.0a2
ro.build.version.incremental=109
ro.build.date=Mon Jun 16 16:51:29 CST 2014
STR: 
Setup MTBF test
Test suite including keyboard, sms, music
Randomly run automation test cases for about 2~6 hours.

EXPECT: Homescreen can be showed correctly

ACTUAL: foreground app was still active. Homescreen completely blank
Attached image photo 2.JPG
System tray is still working
Summary: [MTBF] Can switch to homescreen by home button → [MTBF] homescreen not responding
Blocks: MTBF-B2G
Attached file logcat
Add logcat
blocking-b2g: --- → 2.0?
Attachment #8456816 - Attachment mime type: text/x-vhdl → text/plain
The output of b2g-ps would also be helpful.
One of the many homescreen issues which we will have to investigate given MTBF is <6hours ?
blocking-b2g: 2.0? → 2.0+
Component: General → Gaia::Homescreen
Flags: needinfo?(anygregor)
Blocks: 1015336
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking+]
Whiteboard: [systemsfe]
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking+] → [VH-FL-blocking-][VH-FC-blocking?]
This feels like either a system homescreen launcher bug, or a maybe another content parent issue.
Component: Gaia::Homescreen → Gaia::System::Window Mgmt
(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #5)
> Maybe it's related to bug 1038136?

Not really because it didn't cause crash.

(In reply to Kevin Grandon :kgrandon from comment #6)
> This feels like either a system homescreen launcher bug, or a maybe another
> content parent issue.

Agree. And since symptom is diverse, please tell us what information could help.
Reproduce with build 201407160201

Gaia      aa4f795b81c6147d67c4f06009e166debcf8856e
Gecko     https://hg.mozilla.org/releases/mozilla-aurora/rev/0ec0b9ac39f0
BuildID   20140716160201
Version   32.0a2
ro.build.version.incremental=109
ro.build.date=Mon Jun 16 16:51:29 CST 2014
I can reproduce it, and it looks like a window management issue, having a look!
Assignee: nobody → etienne
Flags: needinfo?(anygregor)
Target Milestone: --- → 2.0 S6 (18july)
Attached file Gaia PR
We had a race conditions where we dispatch |status-active| before the |attentionScreen.getBoundingClientRect().height| has been resized to status-mode (during the slide up transition), which made the layourManager.height computation to return 0.

So the height of the homescreenWindow was set to 0.
Attachment #8458648 - Flags: review?(alive)
Comment on attachment 8458648 [details] [review]
Gaia PR

I guess I should close my eye and r+ because I don't need to care it anymore in 2.1
Attachment #8458648 - Flags: review?(alive) → review+
Yep, this should be the last patch touching the attention screen without test :)
https://github.com/mozilla-b2g/gaia/commit/ff1e998ce3462f1b71e38a174299d3ff82b68df3
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Great work Etienne!
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: