Description: When the X-heavy script has been put on device, accessing the setting app through the message app has major lag. Prereq: Have X-heavy files transferred to the device Repro Steps: 1) Update a Flame device to BuildID: 20141118001204 2) Open 'Message' app 3) Tap the menu icon(...) in upper right corner 4) Tap 'Settings' and observe Actual: Goes to the main Settings page and then, after several seconds, switches to the settings subsection Expected: Should go straight to a subsection of the 'Settings' app Flame 2.1(319mb)(KitKat)(Shallow Flash) Environmental Variables: Device: Flame 2.1 BuildID: 20141118001204 Gaia: 1b231b87aad384842dfc79614b2a9ca68a4b4ff3 Gecko: 95fbd7635152 Gonk: Version: 34.0 (2.1) Firmware: V188-1 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Notes: This is the file count that X-heavy puts onto the device: x-heavy) IMAGE_COUNT=250 MUSIC_COUNT=250 VIDEO_COUNT=50 CONTACT_COUNT=2000 SMS_COUNT=2000 DIALER_COUNT=500 CAL_COUNT=3200 Repro frequency: 100% See attached: logcat, video - http://youtu.be/cAt_wdjO6wE

This issue also occurs on Flame 2.0(319mb) Going to Settings through the Message app with the x-heavy files loaded onto the device causes noticeable lag. Flame 2.0 Device: Flame 2.0 (319mb)(Kitkat Base)(Shallow Flash) Build ID: 20141118000207 Gaia: 1ede2666f1e6c1b3fd3b282011caf0cbc59544b0 Gecko: 2bea026d4f86 Version: 32.0 (2.0) Firmware Version: v188-1 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 Could NOT test the issue on Flame 2.2(319mb) because everytime the X-heavy script was loaded on the device, it bricked. Flame 2.2 Device: Flame 2.2 (319mb)(Kitkat Base)(Shallow Flash) BuildID: 20141118040205 Gaia: 4aee256937afe9db2520752650685ba61ce6097d Gecko: 7913c9392c5f Version: 36.0a1 (2.2 Master) Firmware: V188-1 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Looking at video, it looks more like Settings\Gecko issue and Messages app has nothing to do with it. Forwarding to gaia::settings for now.

Seems like the real issue here is that the user is taken to the main settings page first and then redirected to message settings which is written in bug 1093904

Yeah, i'd say this too. The title is misleading then: is the behavior different with other workloads?

After reviewing the issue more, this does seem to be the same as bug 1093904. The lag will happen whether the x-heavy files are on the device or not.

I think this is really bug 1007600, fixed in v2.2. Bug 1093904 is different: we still see a transition, but not quite as long.