[B2G][Settings][Your Privacy] The privacy links kill the "Settings" app

RESOLVED WORKSFORME

Status

RESOLVED WORKSFORME
5 years ago
5 years ago

People

(Reporter: sarsenyev, Assigned: bkelly)

Tracking

({perf, regression})

unspecified
1.2 C4(Nov8)
ARM
Gonk (Firefox OS)
perf, regression

Firefox Tracking Flags

(blocking-b2g:koi+)

Details

(Whiteboard: [c=memory p= s=2013.11.08 u=1.2] [MemShrink] burirun1)

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
Created attachment 802510 [details]
Log_file.txt

Description:
The "Your privacy" link is required to open browser in the new page, but it kills the "Settings" app

Repro Steps:
1) Updated Buri to Build ID: 20130910040201
2) Launch "Settings" from the home screen
3) Navigate to "Device Information"
4) Navigate to "Your privacy"
5) Tap the link

Actual:
The page opens in the browser and kills the "Settings" app

Expected:
When the browser page opens the "Settings" app is running on background

Environmental Variables
Build ID: 20130910040201
Gecko: http://hg.mozilla.org/mozilla-central/rev/be1053dc223b
Gaia: 6deda9d7c51f278443f704217eaed722044a03e7
Platform Version: 26.0a1

Notes:
Repro frequency: 75% 3 of 5
The log file is attached

Updated

5 years ago
Whiteboard: burirun1
(Reporter)

Comment 1

5 years ago
It's a regression from 1.1
Doesn't reproduce on Leo 1.1
The bug reproduces on all tested  Buri 1.2 m-c builds,
Whiteboard: burirun1 → burirun1, regression

Updated

5 years ago
blocking-b2g: --- → koi?
Keywords: regression, regressionwindow-wanted
Whiteboard: burirun1, regression → burirun1
(Reporter)

Comment 2

5 years ago
The issue reproduces on all Buri 1.2 builds starting from the first 1.2 build on 6/21

Environmental  Variables:
Build ID: 20130621031231
Gecko: http://hg.mozilla.org/mozilla-central/rev/7ba8c86f1a56
Gaia: e2f19420fa6a26c4287588701efaec09a750dba1
Platform Version: 24.0a1
Keywords: regressionwindow-wanted
The log doesn't print out anything conclusive. Might be an OOM issue.
Component: Gaia::Settings → General

Updated

5 years ago
Keywords: perf
Whiteboard: burirun1 → burirun1 [MemShrink]
blocking-b2g: koi? → koi+
Keywords: perf
Whiteboard: burirun1 [MemShrink] → burirun1
Saw this also testing online support links in a customized help page in the settings app.

Updated

5 years ago
Blocks: 891724

Updated

5 years ago
Component: General → Gaia::Settings

Comment 5

5 years ago
If this is an OOM issue, why are you placing this in Gaia rather than a Gecko component. Please help herd this bug as this is a hard blocker obviously.
Component: Gaia::Settings → Gaia
Flags: needinfo?(timdream)
(In reply to Alex Keybl [:akeybl] from comment #5)
> If this is an OOM issue, why are you placing this in Gaia rather than a
> Gecko component. Please help herd this bug as this is a hard blocker
> obviously.

Tim actually placed this in General, which usually tracks misc gecko bugs for Firefox OS. We probably need someone who's knowledgeable on general b2g gecko issues to look into this bug (e.g. fabrice).
Flags: needinfo?(timdream)
Andrew,

Please check if this belongs in your team.
Flags: needinfo?(overholt)
(In reply to sarsenyev from comment #0)
> When the browser page opens the "Settings" app is running on background

This is unfortunate but is expected behaviour AFAIK.

Kyle, any thoughts here?  <s>CANT</s>WONTFIX?
Flags: needinfo?(overholt) → needinfo?(khuey)
Whiteboard: burirun1 → [MemShrink] burirun1
(In reply to Andrew Overholt [:overholt] from comment #8)
> (In reply to sarsenyev from comment #0)
> > When the browser page opens the "Settings" app is running on background
> 
> This is unfortunate but is expected behaviour AFAIK.
> 
> Kyle, any thoughts here?  <s>CANT</s>WONTFIX?

It's not a WONTFIX. This doesn't reproduce on 1.1, which implies a regression on the memory side.
(In reply to Jason Smith [:jsmith] from comment #9)
> (In reply to Andrew Overholt [:overholt] from comment #8)
> > (In reply to sarsenyev from comment #0)
> > > When the browser page opens the "Settings" app is running on background
> > 
> > This is unfortunate but is expected behaviour AFAIK.
> > 
> > Kyle, any thoughts here?  <s>CANT</s>WONTFIX?
> 
> It's not a WONTFIX. This doesn't reproduce on 1.1, which implies a
> regression on the memory side.

I guess.  It could imply a growth in memory usage elsewhere, couldn't it?

I'm still not sure it's a blocking issue, though.  Besides it being intermittent, if you have to re-launch settings, is that a big deal?
(In reply to Andrew Overholt [:overholt] from comment #10)
> (In reply to Jason Smith [:jsmith] from comment #9)
> > (In reply to Andrew Overholt [:overholt] from comment #8)
> > > (In reply to sarsenyev from comment #0)
> > > > When the browser page opens the "Settings" app is running on background
> > > 
> > > This is unfortunate but is expected behaviour AFAIK.
> > > 
> > > Kyle, any thoughts here?  <s>CANT</s>WONTFIX?
> > 
> > It's not a WONTFIX. This doesn't reproduce on 1.1, which implies a
> > regression on the memory side.
> 
> I guess.  It could imply a growth in memory usage elsewhere, couldn't it?
> 
> I'm still not sure it's a blocking issue, though.  Besides it being
> intermittent, if you have to re-launch settings, is that a big deal?

It happens often enough that you'll hit this - I just reproduced this on the first shot trying this right now. And I reproduced this on other links - I saw this with the support links on the help page in a customization. This is relatively easy to reproduce from my perspective.

It's a big deal because this destroys the whole point of the task manager - it's existence is to allow users to return to existing processes that are already active to return back to where they were. In this bug's case, that means selecting hyperlinks to leave the settings app will kill the app in the background immediately, which means users will lose their spot in the settings app if they leave it via a hyperlink. With the existence of this bug & bug 915138, there's a real problem here in regards to memory, so I'm concerned that the memory consumption in our processes has significantly regressed in the 1.2 timeframe. That implies that we'll be able to retain less processes in the background likely overall.
(In reply to Jason Smith [:jsmith] from comment #11)
> [...] In this bug's case, that
> means selecting hyperlinks to leave the settings app will kill the app in
> the background immediately, which means users will lose their spot in the
> settings app if they leave it via a hyperlink.

I'm not sure I agree that this in itself is bad enough to block, but ...

> With the existence of this
> bug & bug 915138, there's a real problem here in regards to memory
                              ^potential
... agreed.
We know that memory use is worse in 1.2.  If we want to deal with that lets hang things off of bug 921659.

I do think conceptually it makes sense that if the Settings app launches the Browser app to display some privacy page that the browser should be killed before settings.  But that requires some work on our OOM priority stuff and definitely isn't a 1.2 feature at this point.

I think we should retest with the patch for bug 927633 and see where we are.  It doesn't look like there's much in the way of low hanging fruit after that on memory usage though.
Flags: needinfo?(khuey)
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #13)
> We know that memory use is worse in 1.2.  If we want to deal with that lets
> hang things off of bug 921659.

A bigger question I think we should figure out is what's acceptable memory-wise for 1.2 ship, especially if we know memory use is worse in 1.2. I'm going to start a side email thread with Sandip to understand this.

> 
> I do think conceptually it makes sense that if the Settings app launches the
> Browser app to display some privacy page that the browser should be killed
> before settings.  But that requires some work on our OOM priority stuff and
> definitely isn't a 1.2 feature at this point.

Note - in the case of this bug, it's a little different. This bug involves launching the browser via a web activity from the settings app to view a URL. Upon going to the browser, the settings app usually gets killed in the background.

Updated

5 years ago
Keywords: perf

Updated

5 years ago
Whiteboard: [MemShrink] burirun1 → [c=memory p= s= u=1.2] [MemShrink] burirun1

Comment 15

5 years ago
Leaving this for MemShrink team to prioritize.

Comment 16

5 years ago
Discussed with Jason. This looks like a pretty "common" use case that the user will come across and notice. Please fix it for 1.2. Can someone at least look into this? If there is a systemic issue here that can be uncovered, that will help us overall in OOM cases.
Jason, can we add testing things here with a recent build to the work in https://bugzilla.mozilla.org/show_bug.cgi?id=921659#c60 ?
Flags: needinfo?(jsmith)
Sure - we can see how the current behavior is right now on this bug.

QA Wanted for a retest to see if the STR still reproduces the bug and how often.
Flags: needinfo?(jsmith)
Keywords: qawanted

Updated

5 years ago
QA Contact: mvaughan

Comment 19

5 years ago
I could NOT reproduce this issue when following the STR from comment 0. The Settings app would terminate after opening privacy policy links about 3-6 times however, and therefore would mean 3-6 privacy policy tabs would be open in the Browser. 

I was able to get the Settings app to terminate after opening only one privacy policy link by using the following STR:

1) Update Buri to v1.2 COM RIL BuildID: 20131108004004
2) Launch the FM Radio app
3) Press the Home button to return to the Homescreen
4) Launch the Settings app
5) Select Device information > Your Privacy > Firefox OS (allow entire privacy policy to load)
6) Long press the Home button to bring up the task manager
7) Swipe over to the Settings app, and then back to the Browser app
8) Tap on the Browser app
9) Long press the Home button again 
**If Settings app window is still present in the task manager, repeat steps 7-9. I did not have to do this more than twice each time I ran through these STR.**

Actual Result:
Settings app is terminated while the Browser and FM Radio apps remain active.

Expected Result:
A "First In, First Out" scenario is followed and the FM Radio app is terminated while the Browser and Settings apps remain active.

Repro Rate: (7/7)

Environmental Variables:
Device: Buri v1.2 COM RIL
BuildID: 20131108004004
Gaia: 4cf40fb30c7b8380ea83ed0d4efe043b8b81737f
Gecko: a886c641a306
Version: 26.0
RIL Version: 01.02.00.019.102
Keywords: qawanted
(Assignee)

Updated

5 years ago
Assignee: nobody → bkelly
Status: NEW → ASSIGNED
(Assignee)

Updated

5 years ago
Whiteboard: [c=memory p= s= u=1.2] [MemShrink] burirun1 → [c=memory p=4 s= u=1.2] [MemShrink] burirun1
I think comment 19 generally implies that this isn't reproducing anymore. The settings app getting killed after 3 - 6 privacy policy links is just the OOM killer killing the process probably cause we ran out of application memory (i.e. expected behavior). That similar rule also applies to the STR described with multiple apps - that sounds like expected behavior.

Sounds like we can close this as a works for me then.
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME

Updated

5 years ago
Whiteboard: [c=memory p=4 s= u=1.2] [MemShrink] burirun1 → [c=memory p= s=2013.11.08 u=1.2] [MemShrink] burirun1
Target Milestone: --- → 1.2 C4(Nov8)
You need to log in before you can comment on or make changes to this bug.