Please report any other irregularities here.
Gecko http://hg.mozilla.org/releases/mozilla-b2g18/rev/282b5c37cf8d Gaia e2ef782119b7e79fc62c48d36f0c36909d982988 BuildID 20130712070210 Version 18.0 Not exactly sure when it has been regressed but after opening I can only see 25 of my >500 contacts. When I scroll down it simply stops, and forces me to use the search feature to find e.g. the 26th person in the list. Steps: 1. Open contacts 2. Scroll down 3. Observe that you can only see 25 contacts If we load contacts in chunks of 25 entries, something might be wrong in loading the next chunk here.
I just tried to reproduce this by flashing a fresh b2g18 and gaia v1-train. I was able to load the reference-workload-heavy list with 1000 contacts fine. Can you provide any additional information about the particular contacts? Are they facebook? Any l10n or distinguishing features of that 26th contact? I'm wondering if there is something unusual about the particular data in that contact causing an exception. Also, logcat would be useful. Thanks!
Imported 106 contacts from SIM card - All 106 showing Tried on both July 11th and July 12th nightlies. Not seeing any issues here. Gecko http://hg.mozilla.org/releases/mozilla-b2g18/rev/aaa74e5efaf1 Gaia 7cdcc46179d198cab11970964b181ede32a5b683 BuildID 20130711070209 Version 18.0 Gecko http://hg.mozilla.org/releases/mozilla-b2g18/rev/282b5c37cf8d Gaia e2ef782119b7e79fc62c48d36f0c36909d982988 BuildID 20130712070210 Version 18.0
Ben - do you have this reference-workload-heavy list? I would like to get my hands on that rather than trying to generate a list of contacts every time.
(In reply to John Hammink from comment #3) > Ben - do you have this reference-workload-heavy list? I would like to get > my hands on that rather than trying to generate a list of contacts every > time. They are in the gaia/master tree. You just need to checkout master and run: make reference-workload-heavy This will copy the contacts and a bunch of other dummy data to your phone. Note, while its only in master, you can still target a phone with v1-train installed on it. Typically you will have to wait a minute or so for the contacts to appear the first time while the database is converted to the right version by gecko. For more info see: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Platform/Gaia/Hacking_Tips_And_FAQ#Reference_Workloads
Those contacts have been imported from Google a while back. Not sure when I scrolled through all contacts the last time. I checked the logcat but there is no useful information. Sorry.
(In reply to Henrik Skupin (:whimboo) from comment #5) > Those contacts have been imported from Google a while back. Not sure when I > scrolled through all contacts the last time. I checked the logcat but there > is no useful information. Sorry. Hmm, well I see two ways to proceed: 1) If you're comfortable with it, you could send me your contacts DB privately. 2) Try selectively removing and adding back contacts to see if a particular contact is the problem. Anyone else have thoughts on how to investigate further?
Ok, I found what's wrong. I was in search mode because at some time I tapped on the search field. But there was no search term entered! I would have expected that all contacts are shown then, and that we do not limit to 25 contacts. When I enter 'a' more than 25 contacts are shown. Steps: 1. Import or create a lot of contacts 2. Open contacts 3. Tap onto the search field 4. Observe that only 25 contacts are visible 5. Tap on a letter to search for, e.g. 'a' 6. Observe that more than 25 contacts are visible I would expect that when no search term is entered we show all contacts. Also the cancel button is not obvious for me. It feels like duplicated ui. I always tapped on the little cross icon to cancel the search, but haven't seen cancel. Not sure, if that's worth another bug or not.
Summary: [Contacts] Only 25 contacts are shown in the contacts application → [Contacts] Having no search term in the search field only 25 contacts are shown
Sorry, even when I enter a single or multiple letters only 25 contacts are visible.
The limit on 25 contacts is intentional for performance reasons: https://github.com/mozilla-b2g/gaia/blob/v1-train/apps/communications/contacts/js/search.js#L32 In regards to how the contacts search field "x" button and the cancel button should behave, lets ask the UX team. UX, for context I think we would like clarification about the following contacts app behavior issues: 1) When clicking the "x" button in the search box, should we remain in search mode or go back to the main list? Currently we stay in search mode until the "Cancel" button is selected. 2) Is it acceptable for the list of contacts to be limited to 25 while in search mode? Currently this hard limit is explicitly coded in for, I believe, performance reasons.
Also, if you don't mind I'm going to back off the leo? nom for now. I know the triage meetings still have difficulty getting through all the bugs, so it would probably help them to see what UX says first.
blocking-b2g: leo? → ---
Based on looking at the discussion in the bug and seeing the bug for myself, I don't think this is a regression. This also exists on 1.01, so yeah, this isn't going to be a blocker based on our leo blocking criteria (i.e. we won't block on something that also reproduces on 1.01 unless it's absolutely critical). I do agree the use of the X button as a way to see the full list of items seems to be a bit awkward. The limit to 25 terms sounds like that was an okay decision for now for performance reasons, although if there are available ways to balance seeing the full list without taking performance hits, then let's explore those options.
Keywords: regression, regressionwindow-wanted
So I did a quick test with 1000 contacts and a hardLimit of 9999: - While typing in the search box you only get one page of results (about 7 contacts) - When you leave the search box (have to click the upper left eyeglass which was confusing to me) then the remaining results are added to the page. - With a search value of 'a', adding the remaing results or canceling to go back to the main list causes a lot of jank. The search tool seems like it was designed to rapidly add/remove nodes from a short list to show the best matching results. It was not designed to do a lot of scrolling. If the contact you want is not visible, type another char, etc. My initial impression is that we should leave the hardLimit at 25 or something close to it for now. If its a priority we could of course work to make the search list scale up.
Just for reference check the contacts application on Android and how fast and correct it shows the appropriate results. There is no hard-limit of 25 contacts only.
+1 to Jason, not a blocker for me.
Flagging Ayman to provide UX input on Contacts. Ayman, this is not blocking.
Flags: needinfo?(firefoxos-ux-bugzilla) → needinfo?(aymanmaat)
(In reply to Ben Kelly [:bkelly] from comment #9) > The limit on 25 contacts is intentional for performance reasons: > > > https://github.com/mozilla-b2g/gaia/blob/v1-train/apps/communications/ > contacts/js/search.js#L32 > > In regards to how the contacts search field "x" button and the cancel button > should behave, lets ask the UX team. > > UX, for context I think we would like clarification about the following > contacts app behavior issues: > > 1) When clicking the "x" button in the search box, should we remain in > search mode or go back to the main list? Currently we stay in search mode > until the "Cancel" button is selected. selecting "x" button in the search box should clear the contents of the search box, but keep the user in search mode. selecting "cancel" button exits search mode completely > > 2) Is it acceptable for the list of contacts to be limited to 25 while in > search mode? Currently this hard limit is explicitly coded in for, I > believe, performance reasons. no its not acceptable to limit the number of results to 25. We should return the full list of results. However i am well aware of the performance reasons around limiting search results to 25 and if there is a technical constraint preventing us from returning the full set of results, from a UX perspective, we have to be pragmatic and accept that this is not a blocker in the sort term. However we do need to fix this eventually... I know that we also have performance issues with loading the full contacts list of the contacts app and therefore i believe we are loading 'chunks' of the list 'on demand' as the user scrolls. If this is so i am wondering if we could reuse or repackage some of the functionality we are employing to load the contacts list in the contacts app to enable contacts search to display more than 25 contacts when the results are returned. NeedInfo to Francisco to get his point of view on this as a path (or not) towards the solution.
Flags: needinfo?(aymanmaat) → needinfo?(francisco.jordano)
Adding perf keyword and koi? flag to get it into the fxos-perf teams triage. I'd like to work this, what I have some other bugs to finish first.
blocking-b2g: --- → koi?
Whiteboard: [ c= p=4 ]
(In reply to ayman maat :maat from comment #16) > However we do need to fix this eventually... I know that we also have > performance issues with loading the full contacts list of the contacts app > and therefore i believe we are loading 'chunks' of the list 'on demand' as > the user scrolls. If this is so i am wondering if we could reuse or > repackage some of the functionality we are employing to load the contacts > list in the contacts app to enable contacts search to display more than 25 > contacts when the results are returned. (In reply to Henrik Skupin (:whimboo) from comment #17) > I believe you mean bug 865747 we are blocked on here. Actually, I think bug 865747 is a bit different. There we are delayed getting the contacts out of the Contacts API which prevents us from rendering the end of the list. The DOM code in the app certainly impacts this as well since we are CPU limited, but its not the only or even the main issue there. In the case of search, we typically will have all the data in the app already and its more just a question of improving how the app manipulates the DOM. We can use some similar techniques, such as the visibility monitor, but the problems really aren't dependent. In all likelihood we can fix/improve this search bug before bug 865747 is fixed.
No longer depends on: 865747
+1 to comment 19
fxos-perf triage: This will require refactoring and doesn't currently block user interaction so minusing this for koi, tracking via our backlog for post-koi (i.e. 1.3).
blocking-b2g: koi? → -
Whiteboard: [ c= p=4 ] → [ c= p=4 s= u=]
Firefox OS is not being worked on
Status: NEW → RESOLVED
Last Resolved: 5 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.