Closed Bug 1154058 Opened 9 years ago Closed 6 years ago

[Messaging][Settings] Messaging settings page takes an exceedingly long time to load when accessed from the Messaging app

Categories

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

ARM
Gonk (Firefox OS)
defect

Tracking

(tracking-b2g:backlog, b2g-v2.2 affected, b2g-master affected)

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

People

(Reporter: dharris, Unassigned)

References

()

Details

(Keywords: regression, Whiteboard: [3.0-Daily-Testing], [spark])

Attachments

(1 file)

Description:
The Messaging settings takes an exceedingly long time to load when accessed from the Messaging app. After 10 tests it took an average of 3.90 seconds to load the Messaging Settings for Flame 3.0. When running 10 tests on Flame 2.2 it took an average of 1.7 seconds to load the Messaging Settings page.

Repro Steps:
1) Update a Flame to 20150413010203
2) Open Messages app
3) Tap on gear Icon to access messaging settings 


Actual:
The messaging settings will take almost 4 seconds to load.


Expected:
The messaging settings will take around 1 second to load

Environmental Variables:
Device: Flame 3.0 (319mb)(Kitkat)(Full Flash)
Build ID: 20150413010203
Gaia: 3c68964cb9fdba7cf0f6829b7f44562acaf1f1d7
Gecko: 0a46652bd992
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 40.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0

Repro frequency: 10/10
See attached: Logcat, Video - https://youtu.be/WF6Mczpp5Mk
This issue DOES occur on Flame 3.0 (512mb Memory)

The messaging settings will take almost 4 seconds to load.

Environmental Variables:
Device: Flame 3.0 (512mb)(Kitkat)(Full Flash)
Build ID: 20150413010203
Gaia: 3c68964cb9fdba7cf0f6829b7f44562acaf1f1d7
Gecko: 0a46652bd992
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 40.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0


This issue does reproduce on Flame 2.2, but the repro rate is very very low. I saw it about 1/20 tries on 2.2. Since this is a performance bug this has been marked as a regression

The messaging settings will take 1.7 seconds to load based on an avarage of 10 tests

Environmental Variables:
Device: Flame 2.2 (319mb)(Kitkat)(Full Flash)
Build ID: 20150413002502
Gaia: cec00d643f517ffd96cde559cd3bbd43ab85816c
Gecko: 5005522fd68e
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 37.0 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
[Blocking Requested - why for this release]:
Noticeable performance regression affecting UX.

Requesting a window.
blocking-b2g: --- → 3.0?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
This is likely due to bug 1151672.
Depends on: 1151672
Component: Gaia::SMS → Gaia::Settings
I encounter the issue on v2.2 1 out of ~5 attempts. Marking v2.2 as affected. I don't think this bug is suitable for a regression window because the repro rate will simply drop as I go back to older builds and the window will not be accurate. Removing window-wanted tag.

On v2.1 when tapping on Settings it goes to Settings app main page first, then after about a second it opens Messaging Settings submenu. This transition seems pretty consistent and if I only count the time of black screen it is almost nonexistent, but if I count the time from tapping on Settings to it really reaching the destination then it takes ~4 seconds, which is even longer time than 3.0 and 2.2.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Pi Wei, is it possible that when you encounter the issue in v2.2 you didn't wait 5 seconds / to compare with the times where you didn't encounter the issue, you did wait 5 seconds?

This would explain the difference.
Flags: needinfo?(pcheng)
There is a major UI difference between v3.0 and v2.2 - on v3.0 when tapping on the gear icon in an empty Messages app (no messages in there), it goes directly to Settings > Messaging Settings. As opposed to on v2.2 when tapping on gear icon it opens a menu first where only Settings is listed as the option, and tapping on that option goes to Settings > Messaging Settings.

As for the question, after further testing I found that v2.2 will more likely reproduce the issue if I had killed the Messages app before attempting the STR. And it does seem to have a relation to timing, if I kill Messages app > open Messages app again > tap Gear icon > tap Settings all in a non-stop motion it seems likely to reproduce. As opposed to if I wait for several seconds after I re-open Messages app, the issue seems less likely to reproduce.
Flags: needinfo?(pcheng)
Thanks, I think this is the difference we see then.

Let's wait until bug 1151672 is fixed and we can see if this bug disappears as well.
need check if this bug disappears
Keywords: qawanted
The bug is still reproducible on Flame and Aries. On Aries the load time is a little big faster about 2 seconds. On Flame it is 4 to 5 seconds as originally reported. The bug is more likely to reproduce if I had killed Messages app prior to doing the steps.

Device: Flame (KK, full flashed, 319MB)
BuildID: 20150720010206
Gaia: 3fac3ed7b8c887351098ffc677769ddc36abb3d0
Gecko: 202e9233d130
Gonk: a4f6f31d1fe213ac935ca8ede7d05e47324101a4
Version: 42.0a1 (2.5 Master) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0

Device: Aries (full flashed, dog food debug build)
BuildID: 20150720101638
Gaia: a47e0c58dd1340a17be7cc96ccd90fcad15a922b
Gecko: 5df788c56ae7
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 42.0a1 (2.5 Master) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Whiteboard: [3.0-Daily-Testing] → [3.0-Daily-Testing], [spark]
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
To be clear, we want to make sure the launch time is short enough if we wait the 5 seconds after the app is launched. Before the 5 seconds we know that there is no preallocated process. But the user is unlikely to launch the Settings page before 5 seconds anyway.
Settings take 4~5s+ to load everything in index.html then jump to specific panel. So if you have settings opened before SMS, the loadtime will be way faster.

We may create a faster channel to handle inline activities in settings...
But we don't care about index.html when we jump to a specific panel...

In the SMS app we did special code to jump to the panel earlier when it was requested, and only then load index.html.
(In reply to Fred Lin [:gasolin] from comment #12)
> Settings take 4~5s+ to load everything in index.html then jump to specific
> panel. So if you have settings opened before SMS, the loadtime will be way
> faster.
> 
> We may create a faster channel to handle inline activities in settings...

Fred, have we identify the root cause of regression (from 1.7s to 4~5s) here? Do we need UX to define the behavior? Thanks.

Triage: +'ing for regression.
Flags: needinfo?(gasolin)
blocking-b2g: 2.5? → 2.5+
take to investigate
Assignee: nobody → gasolin
Flags: needinfo?(gasolin)
Priority: -- → P3
Generally it takes 2.8s(VisuallyLoaded) on flame to show the default panel
https://raptor.mozilla.org/dashboard/script/measures?var-device=flame-kk&var-memory=512&var-branch=master&var-test=cold-launch&panelId=11&fullscreen

Checking startup code, web activity in settings do take longer path by doing extra time consuming lazyload/promise process (activity_handler) then general loading panels.
See Also: → 1214507
After investigation, we found the settings mozActivity is used at SMS to Message Settings panel, Quick Settings to Root panel/Wifi panel/Bluetooth panel... Several activities still navigate to settings root panel, so it looks more reasonable to keep working on Bug 1181023 to improve overall settings loadtime and use the same path to handle activities (instead of create a specific panel only alter-path). 

As offline demo, the Aries has relatively quick response compared with Flame. And this issue/Bug 1181023 will be our consistent work to improve the loadtime, so I think it should not block the release.
blocking-b2g: 2.5+ → 2.5?
Flags: needinfo?(timdream)
See Also: → 1181023
Agreed.

If we still can't make a decision to not block on this issue, it is preferable if QA could do one more check on the launch time (since comment 10 indicates it is 2 sec on Aries but you said it's fairly quick on comment 17 and our offline discussion).
Flags: needinfo?(timdream)
Maybe it was 2sec when Nuwa was broken.

I confirm that on my aries (dogfood build) it's quicker, even when the Settings app is not launched.
However we need to wait 1 more sec to get the right settings state. So I'd say it's ~1sec to launch the panel, and ~1sec to get the stable state.
See Also: → 1216435
Not blocking for 2.5. Its a Perf fix. 
Thanks
blocking-b2g: 2.5? → ---
Assignee: gasolin → nobody
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: