Using a 273mb flame, smart collections just don't work. They quickly OOM themselves after opening, and return you to the homescreen. It doesn't happen *every* time, but after using the phone for a while, it's pretty easy to see. If you do manage to get them to load, try to enter edit mode with pinned items - you'll likely OOM after moving an icon around. This is likely going to be a blocker as I can't even view a smart collection. I think the best fix for this at this point is to move the collection app into the same homescreen process - it's the least risky thing to do for 2.0. Gaia ca022f811bcbbda0f89086094a9e92bb220fea18 Gecko f6aad75c6ac3d3da06406f3570833f29771e217d BuildID 20140714215827 Version 33.0a1 ro.build.version.incremental=109 ro.build.date=Mon Jun 16 16:51:29 CST 2014 B1TC00011220

Fabrice - for Tarako work I believe you implemented something that would allow activities from certified apps to run in the same process? I think it's worth investigating if we can do that with collections. Could you point me to any code as to how we opt-in to that behavior?

The opt-in works by adding a parentApp parameter to the frame config, that holds the parent app's manifest url. How is the smart collection app started?

(In reply to Fabrice Desré [:fabrice] from comment #2) > The opt-in works by adding a parentApp parameter to the frame config, that > holds the parent app's manifest url. How is the smart collection app started? Standard MozActivities from the homescreen. Invoked via: https://github.com/mozilla-b2g/gaia/blob/master/shared/elements/gaia_grid/js/items/collection.js#L99

Thinking about this more, testing this on a 273 flame is not valid due to devicePixelRatio pulling in too large of images. If we can repro this on a Open2, let's revisit.

What's the memory limit? The background image and app icons are the only things I can think of that consume a large amount of memory.

This is running a flame @ 273mb memory. Loading the @1.5x images is not realistic in this case, so we should try with a more realistic setup.

(In reply to Kevin Grandon :kgrandon from comment #4) > Thinking about this more, testing this on a 273 flame is not valid due to > devicePixelRatio pulling in too large of images. If we can repro this on a > Open2, let's revisit. This is wrong. We do *not* support Open II as a reference testing solution in 2.0, so we cannot use that as a valid comparison here. The low memory reference solution must work on 2.0 for testing support. Reopening.

(In reply to Jason Smith [:jsmith] - PTO 7/14 - 7/18 from comment #7) > This is wrong. We do *not* support Open II as a reference testing solution > in 2.0, so we cannot use that as a valid comparison here. The low memory > reference solution must work on 2.0 for testing support. Reopening. No, our 273 target is wrong, it's not a valid reference to a 256mb device. The resolution is way higher than anything that would ship on 256mb, so this is not a valid platform to be testing on.

The reality is that we don't know. Until someone confirms what the resolution is on qrd devices it's meaningless to argue.

Well it turns out we do know the specs, but not sure if we can share them in these bugs. There's no point in chasing bugs if they're not valid and reproduceable on real hardware.

(In reply to Kevin Grandon :kgrandon from comment #10) > Well it turns out we do know the specs, but not sure if we can share them in > these bugs. There's no point in chasing bugs if they're not valid and > reproduceable on real hardware. Based on discussions that occurred in the Flame 2.0 meeting, the conclusion indicated that we do need to support Flame on 273 MB, except with a device spec that matches close to what the QRD currently has. That means this use case does need to work on Flame 273 MB in the 2.0 timeframe, except with a device spec that matches close to the QRD's spec.

(In reply to Jason Smith [:jsmith] - PTO 7/14 - 7/18 from comment #11) > Based on discussions that occurred in the Flame 2.0 meeting, the conclusion > indicated that we do need to support Flame on 273 MB, except with a device > spec that matches close to what the QRD currently has. That means this use > case does need to work on Flame 273 MB in the 2.0 timeframe, except with a > device spec that matches close to the QRD's spec. Right this probably isn't the best place to debate it, but unless we change the 273 spec this still doesn't make sense. Image modifications on @1.5x images do not make sense to do as we do for collections on a 273 device.

Could we please have someone in Taipei QA with an Open 2 test and repro this for us with info

Brian, what do you think? Is it something you can help? Thanks.

Kevin, we don't have Open 2 device to repro. We will need to find if someone has it.

Vance, do you have any Open 2 for us to do test?

Hi Brian, already put 2 Open 2 on your desk Thanks

(In reply to Candice Serran (:cserran) from comment #13) > Could we please have someone in Taipei QA with an Open 2 test and repro this > for us with info Why are you pinging people to test this on Open II? We already concluded at a drivers' level that Flame 273 MB *must* be supported, except with a configuration close to the QRD. We should not be asking for qawanted requests for Open II.

(In reply to Kevin Grandon :kgrandon from comment #12) > (In reply to Jason Smith [:jsmith] - PTO 7/14 - 7/18 from comment #11) > > Based on discussions that occurred in the Flame 2.0 meeting, the conclusion > > indicated that we do need to support Flame on 273 MB, except with a device > > spec that matches close to what the QRD currently has. That means this use > > case does need to work on Flame 273 MB in the 2.0 timeframe, except with a > > device spec that matches close to the QRD's spec. > > Right this probably isn't the best place to debate it, but unless we change > the 273 spec this still doesn't make sense. Image modifications on @1.5x > images do not make sense to do as we do for collections on a 273 device. This is engineering responsibility to figure out how to reconfigure the Flame 273 MB to run under the right configuration close to the QRD. We already concluded that at a drivers' level.

(In reply to Jason Smith [:jsmith] - PTO 7/14 - 7/18 from comment #18) > (In reply to Candice Serran (:cserran) from comment #13) > > Could we please have someone in Taipei QA with an Open 2 test and repro this > > for us with info > > Why are you pinging people to test this on Open II? We already concluded at > a drivers' level that Flame 273 MB *must* be supported, except with a > configuration close to the QRD. We should not be asking for qawanted > requests for Open II. I don't think I have to discuss with you how we should debug our memory issues. We desperately need this info so please don't delay us any further.

(In reply to Gregor Wagner [:gwagner] from comment #20) > (In reply to Jason Smith [:jsmith] - PTO 7/14 - 7/18 from comment #18) > > (In reply to Candice Serran (:cserran) from comment #13) > > > Could we please have someone in Taipei QA with an Open 2 test and repro this > > > for us with info > > > > Why are you pinging people to test this on Open II? We already concluded at > > a drivers' level that Flame 273 MB *must* be supported, except with a > > configuration close to the QRD. We should not be asking for qawanted > > requests for Open II. > > I don't think I have to discuss with you how we should debug our memory > issues. We desperately need this info so please don't delay us any further. We already made a drivers' decision here that we would not pursuing this solution. US QA does not have access to Open II devices & does not have access those builds either. As such, we are not committed to supporting QA requests on the Open II at this time.

(In reply to Jason Smith [:jsmith] - PTO 7/14 - 7/18 from comment #21) > (In reply to Gregor Wagner [:gwagner] from comment #20) > > (In reply to Jason Smith [:jsmith] - PTO 7/14 - 7/18 from comment #18) > > > (In reply to Candice Serran (:cserran) from comment #13) > > > > Could we please have someone in Taipei QA with an Open 2 test and repro this > > > > for us with info > > > > > > Why are you pinging people to test this on Open II? We already concluded at > > > a drivers' level that Flame 273 MB *must* be supported, except with a > > > configuration close to the QRD. We should not be asking for qawanted > > > requests for Open II. > > > > I don't think I have to discuss with you how we should debug our memory > > issues. We desperately need this info so please don't delay us any further. > > We already made a drivers' decision here that we would not pursuing this > solution. US QA does not have access to Open II devices & does not have > access those builds either. As such, we are not committed to supporting QA > requests on the Open II at this time. I also think it is wasteful to pull Brian's team into this - that's going to be overkill if we start pushing a bunch of qawanted requests onto his team in which there's access to a single device & a build that's not off of pvtbuilds (which may or may not match what's tested on Flame pvtbuilds).

Discussed offline - we're granting this as a one-off request, but we're not fully committed to doing this consistently.

edward, pls have someone for this case with Open II.

Even I fresh open II to 2.0 for testing this issue, but one thing you guys should be known that build belong to moz, its not QC build. We cannot 100% use the same environment with QC to do verify this issue. [Environment] Gaia aa4f795b81c6147d67c4f06009e166debcf8856e Gecko https://hg.mozilla.org/releases/mozilla-aurora/rev/0ec0b9ac39f0 BuildID 20140716160201 Version 32.0a2 ro.build.version.incremental=eng.chencong.20140715.162404 ro.build.date=Tue Jul 15 16:25:44 CST 2014 [System memory info] Total 156.7 MB Used - cache 124.8 MB B2G procs (PSS) 70.6 MB Non-B2G procs 54.2 MB Free + cache 31.8 MB Free 8.6 MB Cache 23.2 MB [Result] 1. When user long tap homescreen, the all collections icons will be shown. 2. Collections function is normally after these icons have shown.

(In reply to Edward Chen[:edchen] from comment #25) > Even I fresh open II to 2.0 for testing this issue, but one thing you guys > should be known that build belong to moz, its not QC build. We cannot 100% > use the same environment with QC to do verify this issue. > > [Environment] > Gaia aa4f795b81c6147d67c4f06009e166debcf8856e > Gecko https://hg.mozilla.org/releases/mozilla-aurora/rev/0ec0b9ac39f0 > BuildID 20140716160201 > Version 32.0a2 > ro.build.version.incremental=eng.chencong.20140715.162404 > ro.build.date=Tue Jul 15 16:25:44 CST 2014 > > [System memory info] > Total 156.7 MB > Used - cache 124.8 MB > B2G procs (PSS) 70.6 MB > Non-B2G procs 54.2 MB > Free + cache 31.8 MB > Free 8.6 MB > Cache 23.2 MB > > [Result] > 1. When user long tap homescreen, the all collections icons will be shown. > 2. Collections function is normally after these icons have shown. Edward, is repro'ed on an open II? Is this bug still valid?

(In reply to Candice Serran (:cserran) from comment #26) > (In reply to Edward Chen[:edchen] from comment #25) > > Even I fresh open II to 2.0 for testing this issue, but one thing you guys > > should be known that build belong to moz, its not QC build. We cannot 100% > > use the same environment with QC to do verify this issue. > > > > [Environment] > > Gaia aa4f795b81c6147d67c4f06009e166debcf8856e > > Gecko https://hg.mozilla.org/releases/mozilla-aurora/rev/0ec0b9ac39f0 > > BuildID 20140716160201 > > Version 32.0a2 > > ro.build.version.incremental=eng.chencong.20140715.162404 > > ro.build.date=Tue Jul 15 16:25:44 CST 2014 > > > > [System memory info] > > Total 156.7 MB > > Used - cache 124.8 MB > > B2G procs (PSS) 70.6 MB > > Non-B2G procs 54.2 MB > > Free + cache 31.8 MB > > Free 8.6 MB > > Cache 23.2 MB > > > > [Result] > > 1. When user long tap homescreen, the all collections icons will be shown. > > 2. Collections function is normally after these icons have shown. > > Edward, is repro'ed on an open II? [Edward] The bug does not reproduce on an open II. Is this bug still valid? [Edward] I think this bug is worksforme. It should be keep monitor this bug on a flame devices.

It seems that bug 1029902 will fix this regardless as the homescreen uses a lot less memory (does not get oom'd)

Now that we have landed bug 1040070, this is working fine for me due to homescreen memory savings.

This issue has been verified successfully on Flame 2.0, 2.1. See attachment: 1135.MP4 Reproducing rate: 0/5 Actual result: 1. When user long tap homescreen, the all collections icons will be shown. 2. Collections function is normally after these icons have shown. Flame 2.1 version(273m): Gaia-Rev 38e17b0219cbc50a4ad6f51101898f89e513a552 Gecko-Rev https://hg.mozilla.org/releases/mozilla-2g34_v2_1/rev/8b92c4b8f59a Build-ID 20141205001201 Version 34.0 Device-Name flame FW-Release 4.4.2 FW-Incremental eng.cltbld.20141205.035305 FW-Date Fri Dec 5 03:53:16 EST 2014 Bootloader L1TC00011880 System memory info: Total 169.6 MB SwapTotal 192.0 MB Used - cache 124.3 MB B2G procs (PSS) 75.0 MB Non-B2G procs 49.3 MB Free + cache 45.3 MB Free 8.3 MB Cache 37.0 MB SwapFree 137.8 MB Flame 2.0 version(273m): Gaia-Rev 856863962362030174bae4e03d59c3ebbc182473 Gecko-Rev https://hg.mozilla.org/releases/mozilla-2g32_v2_0/rev/e40fe21e37f1 Build-ID 20141207000206 Version 32.0 Device-Name flame FW-Release 4.4.2 FW-Incremental eng.cltbld.20141207.034341 FW-Date Sun Dec 7 03:43:52 EST 2014 Bootloader L1TC00011880 System memory info: Total 169.6 MB SwapTotal 192.0 MB Used - cache 135.3 MB B2G procs (PSS) 62.2 MB Non-B2G procs 73.1 MB Free + cache 34.4 MB Free 6.4 MB Cache 27.9 MB SwapFree 107.8 MB