User-Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0 When opening the contacts app I expect to be able to immediately scroll through my list of contacs that is fully populated. Instead the first page (or so) is full but then scrolling down shows only empty slots. The rest of the contacts take about 10 seconds to show up.
Triage: The contacts team made some performance improvement on 2.2 (bug 1112551). It was tested against 2000 contacts. Does it happen at every start up of the contact app? Do you know how many contacts you have? Do they have all an image?
QA Whiteboard: [foxfood-triage]
Component: Gaia::Feedback → Gaia::Contacts
See Also: → bug 1112551
I have about 1500 contacts. Most have an image. It happens every time I start up the app. Let me know how I can provide more info.
QA wanted for a video.
This should be cached in the localStorage. What should take longer is the load of all the images, but at least the contact information should be displayed fast. Looking forward for that video :S
Video: https://youtu.be/FdADLBduwh4 Confirming this issue is occurring in Flame Kk 2.5 and 2.2 Result: For about 3-4 seconds large amount of contacts will not appear quickly when scrolling through list. There does seem to be an improvement here. Environmental Variables: Device: Flame 2.5 Kk Full Flash (319mb) Build ID: 20150721010202 Gaia: 4fe0507781f3ed56c8ae5e66dd9489165d1ff68e Gecko: 3a4bfa5d2d02 Gonk: 41d3e221039d1c4486fc13ff26793a7a39226423 Version: 42.0a1 (2.5) Firmware Version: v18D User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0 Environmental Variables: Device: Flame 2.2 Kk Full Flash (319mb) BuildID: 20150721002506 Gaia: e1e6317f17a840b19af9dbb25f5a771d8d9fa161 Gecko: 1bc400014f71 Gonk: bd9cb3af2a0354577a6903917bc826489050b40d Version: 37.0 (2.2) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0 ---------------------- This issue is not occurring on Flame 2.1 and 2.0 Result: Contacts do not appear instantaneously however there is only about a second delay. Environmental Variables: Device: Flame 2.1 Kk Full Flash (319mb) Build ID: 20150721001206 Gaia: cc24cce17ab2ebf79f6505103da714fc65bc5ec1 Gecko: 3856aebece7b Gonk: bd9cb3af2a0354577a6903917bc826489050b40d Version: 34.0 (2.1) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Environmental Variables: Device: Flame 2.0 Kk Full Flash (319mb) BuildID: 20150721000210 Gaia: b16ba05481e577bc644ed8966f587a70fe2148e6 Gecko: 69dcc68fad52 Gonk: bd9cb3af2a0354577a6903917bc826489050b40d Version: 32.0 (2.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [foxfood-triage] → [QAnalyst-Triage?][foxfood-triage]
status-b2g-v2.0: --- → unaffected
status-b2g-v2.1: --- → unaffected
status-b2g-v2.2r: --- → affected
status-b2g-master: --- → affected
Keywords: qawanted → regression
QA Whiteboard: [QAnalyst-Triage?][foxfood-triage] → [QAnalyst-Triage+][foxfood-triage]
I don't remember the loading being that bad while testing bug 1112551. This might be a graphics issue. What do you think guys?
I would say so, but I've not seen that in master
We are only caching the first chunk of contacts and that's being shown very fast on the screen, but the rest of the list is loaded on chunks of data that we get from the Contacts API so it's a bit slower. However, it shouldn't be as slow as it is shown in the video, at least I don't remember it that slow while working on bug 1112551 . It would be good to check if the list loads as slow as it is shown in the video with bug 1112551 as the head commit. If the performance is better in that case, then we'll need to ask for a regression window. In any case, one of the possible follow ups of bug 1112551 that we could do at some point is to also cache the result of rendering each contacts group outside of the first chunk and append them incrementally to the DOM via documentFragment, instead of appending contact by contact as we get them from the Contacts API, as we are currently doing.
Firefox OS is not being worked on
Status: NEW → RESOLVED
Last Resolved: 18 days ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.