Closed Bug 1136595 Opened 9 years ago Closed 9 years ago

[Privacy Panel] Privacy panel will be closed when unlocking device or entering card view

Categories

(Firefox OS Graveyard :: Gaia::Settings, defect, P1)

ARM
Gonk (Firefox OS)

Tracking

(b2g-v2.2 affected, b2g-master affected)

RESOLVED WONTFIX
Tracking Status
b2g-v2.2 --- affected
b2g-master --- affected

People

(Reporter: gchang, Unassigned)

References

()

Details

Attachments

(1 file)

### Steps:
1. Open Settings app
2. Navigate to Privacy Controls > Location Accuracy
3. Press power button twice to access lockscreen
4. Unlock screen

### Actual:
1. The privacy control is closed and homescreen shows up

### Expected:
1. The privacy control should not be closed and remains in screen.

### Reproduce rate
always

### Version:
Gaia-Rev        ca64f2fe145909f31af266b1730874051ba76c78
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/16804008c29f
Build-ID        20150224162516
Version         37.0
Device-Name     flame
FW-Release      4.4.2

I also found that the privacy control will be closed when entering card views.
After launching privacy control: the processes are
root@flame:/ # b2g-info                                                        
                           |     megabytes     |
           NAME   PID PPID CPU(s) NICE  USS  PSS   RSS SWAP VSIZE OOM_ADJ USER     
            b2g   210    1  725.5    0 77.0 83.8 107.4  0.0 268.4       0 root     
         (Nuwa)   439  210    1.0    0  4.1  6.6  21.3  0.0  64.6     -16 root     
Built-in Keyboa  1019  439   13.5    0  8.0 10.1  26.0  0.0  74.3      11 u0_a1019 
     Homescreen  1121  210  102.7    0 19.2 22.8  39.7  0.0 107.6       8 u0_a1121 
OperatorVariant  1224  439    1.4    0  5.2  6.9  20.6  0.0  71.1      13 u0_a1224 
          Usage  1379  439   16.6    0  8.5 10.5  26.2  0.0  73.8      12 u0_a1379 
Smart Collectio  1504  210    4.6    0 14.2 17.5  33.4  0.0  78.8      13 u0_a1504 
 Find My Device  1968  439    4.9    0  6.6  8.4  22.9  0.0  71.1      12 u0_a1968 
       Settings 10495  439   14.6    0 14.4 16.5  32.2  0.0  89.0      10 u0_a10495
Privacy Control 12654  439    3.8    0 22.3 24.6  40.8  0.0 127.1       2 u0_a12654
(Preallocated a 13489  439    0.1    0  4.7  6.3  16.0  0.0  70.2       1 u0_a13489


Entering card views by long pressing home button: privacy control is closed, and the processes are:
root@flame:/ # b2g-info                                                        
                           |     megabytes     |
           NAME   PID PPID CPU(s) NICE  USS  PSS   RSS SWAP VSIZE OOM_ADJ USER     
            b2g   210    1  727.7    0 82.3 89.2 112.3  0.0 266.3       0 root     
         (Nuwa)   439  210    1.0    0  4.9  7.2  21.3  0.0  64.6     -16 root     
Built-in Keyboa  1019  439   13.5    0  8.0 10.3  26.0  0.0  74.3      11 u0_a1019 
     Homescreen  1121  210  102.8    0 19.2 23.0  39.7  0.0 106.6       8 u0_a1121 
OperatorVariant  1224  439    1.4    0  5.2  7.1  20.6  0.0  71.1      13 u0_a1224 
          Usage  1379  439   16.6    0  8.5 10.7  26.2  0.0  73.8      12 u0_a1379 
Smart Collectio  1504  210    4.6    0 14.2 17.6  33.4  0.0  78.8      13 u0_a1504 
 Find My Device  1968  439    4.9    0  6.3  8.5  22.9  0.0  71.1      12 u0_a1968 
       Settings 10495  439   14.6    0 14.0 16.5  32.2  0.0  88.0      11 u0_a10495
(Preallocated a 13489  439    0.2    0  5.3  6.6  15.8  0.0  70.1       1 u0_a13489
Attached file The logcat
NI developer for this issue.
blocking-b2g: --- → 2.2?
QA Whiteboard: [COM=Privacy Panel]
Flags: needinfo?(huseby)
Severity: normal → major
blocking-b2g: 2.2? → 2.2+
Priority: -- → P1
Is this really falls under Settings app? Is this still a blocker after bug 1132377?
I just debugged this and I noticed a couple of things:

* It appears that an inner-window-destroyed observe messages gets delivered to the settings manager just before the privacy controls gets killed.

> I/Gecko   ( 1605): -*- SettingsManager: Received: inner-window-destroyed for valid innerWindowID=4, cleanup.

* It also appears that the lock screen has something to do with it.  Here are my steps:

1. Launch Settings > Privacy Controls.
2. run 'adb shell b2g-ps' and see that the Privacy Control process is in the list.
3. press the power button once to lock the screen.
4. run 'adb shell b2g-ps' and see that the Privacy Control process is still in the list.
5. press the power button once to get to the lock screen.
6. run 'adb shell b2g-ps' and see that the Privacy Control process is now gone.

* Just before the inner-window-destroyed observe message is delivered, there is a warning about the verticalhome app calling mozLockOrientation and it returning false.

> W/GeckoConsole(  307): Content JS WARN: screen.mozLockOrientation() returned false for app://verticalhome.gaiamobile.org orientation default 
> W/GeckoConsole(  307):     at AppWindow.prototype.lockOrientation (app://system.gaiamobile.org/js/app_window.js:1582:8)

I think there is something in system and/or the lock screen and/or the homescreen that is killing the Privacy Controls process.  I don't believe it to be a resource contention issue.
Flags: needinfo?(huseby)
Hi Alive, Greg, can you verify Comment 4 about the system/lockscreen part?
Flags: needinfo?(gweng)
Flags: needinfo?(alive)
How is Privacy Panel implemented?
An app? An inline activity? An attention window? An individual in process iframe inside system app?
> I think there is something in system and/or the lock screen and/or the homescreen that is killing the Privacy Controls process.  I don't believe it to be a resource contention issue.

Howie, I've no idea what you want me to comment...as a content space content lock screen never be able to control ("killing") process, and I'm sure it doesn't do that. I even don't believe System app has such ability to control process directly.

If you mean LockScreen does something and thus unintentionally make the panel process gone, since it's a process level issue, I'm afraid of that I don't have any clue about how these platform things going.
Flags: needinfo?(gweng)
Ok, so privacy control in settings is calling mozApps launch for privacy "app" exactly.

Then I will say this is a WORKSFORME or WONTFIX because it's the normal behavior to kill a background app.
This would be a bug ONLY if the app is killed before you lock the device.

After you lock the device, any app is possible to be killed if it's using too many memory.

If you really want to fix this, change the behavior of ProcessPriorityManager or make Privacy Control app more light-weight.
blocking-b2g: 2.2+ → 2.2?
Flags: needinfo?(alive)
Per comment 8
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
blocking-b2g: 2.2? → ---
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: