Closed Bug 813262 Opened 12 years ago Closed 12 years ago

Cost control widget process stays "foreground" as long as phone screen is turned on

Categories

(Firefox OS Graveyard :: Gaia::Cost Control, defect, P3)

ARM
Gonk (Firefox OS)
defect

Tracking

(blocking-basecamp:+)

RESOLVED DUPLICATE of bug 810453
blocking-basecamp +

People

(Reporter: cjones, Assigned: salva)

References

Details

cjones@beast:~[]$ adb reboot cjones@beast:~[]$ adb shell b2g-ps | grep Cost Cost Control app_0 359 106 63084 22568 ffffffff 400e2330 S /system/b2g/plugin-container 1. Turn on phone screen, so that we're at the lock screen: cjones@beast:~[]$ adb shell cat /proc/359/oom_adj 1 2. Unlock lock screen: cjones@beast:~[]$ adb shell cat /proc/359/oom_adj 1 3. Pull down system tray: cjones@beast:~[]$ adb shell cat /proc/359/oom_adj 1 4. Close system tray: cjones@beast:~[]$ adb shell cat /proc/359/oom_adj 1 5. Turn off screen: cjones@beast:~[]$ adb shell cat /proc/359/oom_adj 6 6. Turn screen back on (go to lock screen): cjones@beast:~[]$ adb shell cat /proc/359/oom_adj 1 Expected results are that cost control's oom_adj values are 1. 6 (background) [buggy] 2. 6 [buggy] 3. 1 (foreground) [correct] 4. 6 [buggy] 5. 6 [correct] 6. 6 [buggy] This is a very bad bug because it will essentially lock all the cost control memory in RAM; cost control won't be able to be killed on memory pressure.
> This is a very bad bug because it will essentially lock all the cost control memory in RAM; cost > control won't be able to be killed on memory pressure. I've been ignoring all bugs related to the cost-control process because I was under the impression that we were removing the cost-control process altogether. Is that still the plan?
I had hoped this was related to bug 813243 but it appears like it's not. (In reply to Justin Lebar [:jlebar] from comment #1) > > This is a very bad bug because it will essentially lock all the cost control memory in RAM; cost > > control won't be able to be killed on memory pressure. > > I've been ignoring all bugs related to the cost-control process because I > was under the impression that we were removing the cost-control process > altogether. > > Is that still the plan? The cost control *service* is no longer needed and should (already?) be dead. This is the cost control *widget*, the UI part. This isn't going anywhere.
I had hoped this bug was related to bug 813243, but it appears not.
Assignee: nobody → salva
Depends on: 810453
No longer depends on: 810453
Depends on: 810453
Component: Gaia → Gaia::Cost Control
blocking-basecamp: ? → +
Priority: -- → P3
Re-testing with bug 810453 applied 1. Turn on phone screen, so that we're at the lock screen: cjones@beast:~[]$ adb shell cat /proc/`adb shell b2g-ps | grep 'Cost Control' | awk '{print $3}'`/oom_adj /proc//oom_adj: No such file or directory 2. Unlock lock screen: cjones@beast:~[]$ adb shell cat /proc/`adb shell b2g-ps | grep 'Cost Control' | awk '{print $3}'`/oom_adj /proc//oom_adj: No such file or directory 3. Pull down system tray: cjones@beast:~[]$ adb shell cat /proc/`adb shell b2g-ps | grep 'Cost Control' | awk '{print $4}'`/oom_adj 1 4. Close system tray: cjones@beast:~[]$ adb shell cat /proc/`adb shell b2g-ps | grep 'Cost Control' | awk '{print $4}'`/oom_adj 1 5. Turn off screen: cjones@beast:~[]$ adb shell cat /proc/`adb shell b2g-ps | grep 'Cost Control' | awk '{print $4}'`/oom_adj 6 6. Turn screen back on (go to lock screen): cjones@beast:~[]$ adb shell cat /proc/`adb shell b2g-ps | grep 'Cost Control' | awk '{print $4}'`/oom_adj 1 Expected results are that cost control's oom_adj values are 1. 6 (background) [OK] 2. 6 [OK] 3. 1 (foreground) [OK] 4. 6 [buggy] 5. 6 [OK] 6. 6 [buggy] So looks like we still have some work to do here that doesn't have to do with background services.
No longer depends on: 810453
More specifically, since IIRC cost control is managed as a special case, we'll probably need a patch like the one in bug 810453 for that special-case code.
(In reply to Chris Jones [:cjones] [:warhammer] from comment #5) > More specifically, since IIRC cost control is managed as a special case, > we'll probably need a patch like the one in bug 810453 for that special-case > code. The code for controlling visibility of Cost Control is here: https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/cost_control.js#L54 What could it be?
I confirmed that these show/hide statements are successfully being hit. As I recall, cost control does a window.open(). I suspect that that window is not being set to background. Checking. (I have no idea which embedder will end up handling that call ...)
We're reaching the code added in bug 810453, but then I/GeckoDump( 1848): COST CONTROL: could not hide: TypeError: frame.setVisible is not a function jlebar, halp? Popups of mozbrowser frames aren't also mozbrowser?
Flags: needinfo?(justin.lebar+bug)
> jlebar, halp? Popups of mozbrowser frames aren't also mozbrowser? Bug 810431. And, sorry about that.
Flags: needinfo?(justin.lebar+bug)
Some code has a bug? Perish the thought! ;) The suggested workaround should suffice here.
Depends on: 810431
Works like a charm. Nothing more to do here.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.