Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me) Reporter
	Description • 10 years ago

STR:

1) open browser app 
2) type a url in device and click on go 

Obs:
1) browser app shows website.. 
2) but i am seeing that two instance of browser app is running on device in |adb shell b2g-info| . if i kill browser app using 'card view' then one instance is killed but other instance is not killed till i run |adb shell kill XXXX| command.

This is causing extra memory usage in v2.1 device than v2.0 

Issue is easily reproducible in v2.1 gaia/gecko:

https://www.codeaurora.org/cgit/quic/lf/b2g/mozilla/gaia/commit/?h=mozilla/v2.1&id=0f76e0baac733cca56d0140e954c5f446ebc061f
https://www.codeaurora.org/cgit/quic/lf/b2g/mozilla/gecko/commit/?h=mozilla/v2.1&id=8b1097858fef8d21d85adba4f8d48dd3d53c6059

	Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me) Reporter
	Comment 1 • 10 years ago

[Blocking Requested - why for this release]:

	KTucker [:KTucker][Inactive 3/4/2016]
	Comment 2 • 10 years ago

Adding qawanted for branch checks.

	Chris Kreinbring [:CKreinbring]
	Comment 3 • 10 years ago

The bug repros on Flame 2.2 and Flame 2.1.  Flame 2.2 was on full flash and 2.1 was on shallow.
Actual result: When the Browser app is launched, two instances are seen when the b2g-info command is used.

Flame 2.2
BuildID: 20141024070214
Gaia: 29ed78a26d62b58f663437a45f273d57b9781d79
Gecko: d6abb9bf43be
Platform Version: 36.0a1
Firmware Version: V188
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Flame 2.1
BuildID: 20141024064808
Gaia: 07cd1562b90960a343104a67b184cf9e01bee8a0
Gecko: 4feccadc6146
Platform Version: 34.0
Firmware Version: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

--------------------------------------------------------------------------------------------------------

The bug does not repro on Flame 2.0 on shallow flash.
Actual result: When the Browser app is launched, only one instance is seen when the b2g-info command is used.

BuildID: 20141024064809
Gaia: 1a89b5317dbc31da9c604d677a4a5a3e34122a17
Gecko: cfa7cdcb728b
Platform Version: 32.0
Firmware Version: V180
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

	Gregor Wagner [:gwagner]
	Comment 4 • 10 years ago

Bad regression

	Ben Francis [:benfrancis] Assignee
	Comment 5 • 10 years ago

Stupid question: is this just the search app showing up in the list of processes?

	Ben Francis [:benfrancis] Assignee
	Comment 6 • 10 years ago

My hypothesis is that the extra process you're seeing is the search app, which would be expected behaviour in 2.1+.

However, as I carry out actions on the device and monitor the changes in processes shown by "ps | grep b2g" I see some quite confusing results that don't entirely make sense to me...

* Boot device
 +206(root)
 +443(root)
 (system app boot screen shows)
 +936
 (homescreen app starts)
 +1192
 Note: rocketbar-results is empty in DOM
* Launch browser (search app)
 +1752
 Note: appWindow created with mozapp=search.gaiamobile.org, src=search.gaiamobile.org/newtab
* Start typing in Rocketbar
 (no change)
* Hit enter
 +2271
 Note: appWindow changes to browserWindow with mozapp=false, src=google.com
* Kill browser window from task manager
 -1752
* Delete searchWindow from DOM
 -1192
* Delete homescreenWindow from DOM
 -936
* kill 2271
 (nothing visible happens)
* kill 206
 B2G restarts

Need to investigate further to fully understand what's going on.

	Ben Francis [:benfrancis] Assignee
	Comment 7 • 10 years ago

Closed by mistake.

	Ben Francis [:benfrancis] Assignee
	Comment 8 • 10 years ago

Ah OK, the preallocated B2G processes were confusing me. b2g-ps gives more comprehensible results.

I have confirmed that one "Browser" process is the search app, and the other one is the browser window. If you just tap a top site or history result on the browser start page (part of the search app) then the "Browser" process of the search app window will be replaced by a "Browser" process of a browser window. If however you type into the Rocketbar it will kick a search window of the search app into action. In this case the process will stick around even after you navigate to a web page so that it can be re-used when you type into the Rocketbar again. A single search app process is shared by the search window (Rocketbar results) and any search app windows (browser start page), but there is only ever one of them. This process should be killed in low memory situations so shouldn't cause any problems.

For reference, the steps I carried out with today's master branch were:

* Boot device
 +202 (b2g)
 +382 (Nuwa)
 +950 (Preallocated)
* Homescreen app starts
 950 becomes homescreen
 +1241 (Preallocated)
* Start browser (search app)
 1241 becomes Browser (search app)
 +1552 (Preallocated)
* Start typing
 (no change)
* Hit enter
 1552 becomes Browser (browser window)
 +1840 (Preallocated)
* Kill browser window
 -1552 (browser window)
 Note: search app process remains in the background
* Start browser (search app) again
 (no change, 1241 is re-used for the search app)
* Kill search app
 (no change, rocketbar results still using the process in background)
* Delete rocketbar-results from DOM
 -1241 (search app process is killed)


I also compared with the commit from before bug 1071882 landed, and the results differ in the expected way. That patch reduced the likelihood of a search app process sticking around by implementing the switching behaviour I described above.

* Boot device
 +219 (b2g)
 +447 (Nuwa)
* System app starts
 +940 (preallocated)
* Homescreen app starts
 940 becomes homescreen
 +1231 (Preallocated)
* Start browser (search app)
 1231 becomes Browser (search app)
 +1587 (Preallocated)
* Start typing
 (no change)
* Hit enter
 1587 becomes Browser (browser window)
 +1884 (Preallocated)
* Kill browser window
 -1587 (browser window)
* Kill search app
 (no change) - search app process sticks around
* Start browser (search app) again
 1231 is re-used
* Navigate to URL
 1884 becomes browser window
 +2161 (Preallocated)