maemo.org Bugzilla – Bug 6099
Incremental search function is case sensitive for HildonTouchSelectorEntry
Last modified: 2010-06-03 19:30:52 UTC
You need to log in before you can comment on or make changes to this bug.
For web form elements like drop-down menus or these boxes where you can choose one or more entries (see Attachments 1 and 2) there is a search field in the top of the "select objects" dialogue where you can search elements inside of the drop-down menu. Input to these search field works case sensitive. A lot of list elements in drop down menus are beginning with a big letter so it's hard to get accordance for the first letter. The search field seems to be available only if there are many list elements. STEPS TO REPRODUCE THE PROBLEM: 1. Open the browser 2. Go to https://bugs.maemo.org/query.cgi?format=advanced 3. Tip into the list called "Product" on the left side. -> a selct objects dialogue including all the list elements comes up to let you choose elements finger friendly. (See Attachments) 4. Select the search field and begin to input the word "calendar" (in small letters!) EXPECTED OUTCOME: The calendar element is selected. ACTUAL OUTCOME: nothing happens (see Attachment1 [details]). If you try step 4 writing calendar like "Calendar" it works correctly (see Attachment2 [details]). REPRODUCIBILITY: always This at least happens in multiple choice list elements (Attachments 1 and 2) and drop-down menus. On the area: "Advanced Searching Using Boolean Charts" on this page: https://bugs.maemo.org/query.cgi?format=advanced there is a drop-down menu with a lot of list items to reproduce this issue (See Attachment3 [details]).
Created an attachment (id=1559) [details] Attachment1 [details] - No incremental search using lower case letters
Created an attachment (id=1560) [details] Attachment1 [details] - Incremental search works fine using upper case letter at the begin of a string
Created an attachment (id=1561) [details] Attachment1 [details] - Example for a drop down menu with many list elements on https://bugs.maemo.org/query.cgi?format=advanced
yep, we know. this is actually a rat's nest. this isn't an excuse, but it's an exercise: open clock. go to world times. add a zone tap the magnifying glass type "bogot", you should see a place in "Columbia". Now type an "a", so you're searching for "bogota", you will see nothing. so, the clock is accent sensitive and it searches on substrings (search for "Lonia" and you'll find Colonia, Micronesia) Address book is case insensitive, stop character challenged, and accent sensitive a contact named "Test (Domain/Range)" -- with the quotes (I'm told the quotes are a contribution by Modest), is searchable by '(Domain' but not by 'Test', actually, if you look you'll see that modest contributed first name '"Test' and last name '(Domain/Range)"' Sadly, I can't easily prove to you that this is a bug in the system widget, because afaict no one else uses it! but believe me, we're using a standard system widget (always a mistake) We all know that Maps isn't a native app, and i'll leave discussion about its search behavior to another day feed reader doesn't do live search. nor does file manager. and mail only has find in message (not find messages). media player/image viewer only offer tag based filtering. actually, there are a host of problems with browser's impl, it's not actually doing filtering (at least not here), and it's whole string instead of by word (i wrote a spec internally defining what it should do, and am of course annoyed it wasn't implemented), and it leaves turds if you use a multiselect. It looks like internal builds stopped offering search entirely because of the turd problem (this is best experienced by selecting the product field and typing a couple of letters [Cont]). The explanation given by the widget team was something like "that's not a supported feature, you could implement a custom widget". So. Can I mark this as "fixed" (because search is no longer case sensitive -- it doesn't exist at all)?
OK. So, proof that this is a widget system bug: 1. install OMWeather 0.24.8 2. open OMWeather [please don't idle too long in OMWeather, IME it will crash/quit if you don't give it enough attention] 3. tap the wrench 4. tap a station 5. wait for the next dialog 6. tap Country 7. type "a" (this will appear as "A") 8. press <backspace> (this will clear your string) 9. press "u" (this will appear as "U") 10. press "n" (this will appear as "n") 11. press <right-arrow> (this will result in "United ") 12. press "s" (this will result in "United s") At this point, you will not have "United States" (bug 5995) selected or even visible, instead you'll have "United Arab Emirates" selected and "United Kingdom" visible. The facts that the list doesn't filter (and instead merely jumps) and that the list is case sensitive are all nicely demo'd here. (And are bugs for any real user, and result in the dialog not performing well, and don't match how Contacts/Clock work) As such, I'm now able to move this out of the browser component (as I said earlier, the widget is unhelpful). I'm going to post a spec for how this should work elsewhere in the hopes that someone will write a patch to do the right thing (tm) and then let people use that patched widget instead of the Nokia widget. Given that no one on the platform wants the widget behavior (see Clock, Address Book), it'd be nice if the widget were fixed.
Not fixed in 1.2009.42-11
Adding alias of internal bug
(In reply to comment #5) > I'm going to post a spec for how this should work elsewhere in the > hopes that someone will write a patch to do the right thing (tm) and > then let people use that patched widget instead of the Nokia widget. I agree that the user experience in your example sucks, but note that a general solution might not be completely obvious. So, if you type 'United s', what would you expect? 1) "United States" highlighted and the text remaining as "United s" ? 2) "United States" highlighted and the text replaced with "United S" ? 3) The list scrolling to "United States" to show that it's there, but without changing the entry in the text or the highlighted item ? Also, when an item in the list matches part of the text that you've typed, the text entry is _replaced_ to contain the suggested completion, so you can confirm it by pressing the right arrow. So what would you do if the user is e.g. selecting a rock band, starts typing 'Hea' and the band "HEALTH" is in the list? Would you convert to uppercase the part of the text that has already been written? And what if you have both 'HEALTH' and 'Heaven 17' in the list? What would you do in that case? It would be great if we can find a good solution for this, but please take into account cases like the ones I've just explained.
Created an attachment (id=1721) [details] A possible solution (In reply to comment #8) > 3) The list scrolling to "United States" to show that it's there, > but without changing the entry in the text or the highlighted > item ? For the record, we already have an initial patch with this solution (I'm attaching it here). The idea is that we want people to look for an item without worrying about the case, but we also don't want to change text that has already been written. This is just an initial implementation and hasn't been tested much. If you like the idea, it could be extended to e.g. cover also accented characters. Opinions are welcome.
Created an attachment (id=1770) [details] Patch that ignores case and accents This patch ignores both case and accents (I haven't renamed the property yet but you get the idea).
I've tested this latest patch with a list of a thousand items in the N900 and it works fine performance-wise. But I've noticed what I think is a bug in the current implementation. When you have a list with multiple selection (e.g the aforementioned 'Products' combo in bugs.maemo.org) partial matches remain selected, so if you type 'Canola' both 'Calendar' and 'Canola' will be highlighted. I'll upload an updated patch that fixes this too.
(In reply to comment #11) > When you have a list with multiple selection (e.g the aforementioned > 'Products' combo in bugs.maemo.org) partial matches remain selected, Ah, these must be the 'turds' mentioned above ;)
(In reply to comment #12) > (In reply to comment #11) > > When you have a list with multiple selection (e.g the aforementioned > > 'Products' combo in bugs.maemo.org) partial matches remain selected, > There is such a bug in Nokia bugzilla. The problem, from my understanding, is in using multiple selection with a HildonTouchSelectorEntry, which is obviously wrong.
(In reply to comment #13) > > > When you have a list with multiple selection (e.g the > > > aforementioned 'Products' combo in bugs.maemo.org) partial > > > matches remain selected, > There is such a bug in Nokia bugzilla. Yeah, I've just seen it (int-140131) > The problem, from my understanding, is in using multiple selection > with a HildonTouchSelectorEntry, which is obviously wrong. I see the use case mentioned in the bug report. However now that we have just added the live search functionality to HildonTouchSelector I think it's better to use live search for this use case and leave the HildonTouchSelectorEntry as it is.
Still valid in 1.2009.51-1
I've just committed the patch (an updated one): http://maemo.gitorious.org/hildon/hildon/commit/0d0dc456cbc4f99763c013339aeef84ed6e7758d
This has been fixed in package libhildon 2.2.12-1+0m5 which is part of the internal build version 10.2010.06-14 (Note: 2009/2010 is the year, and the number after is the week.) A future public update released with the year/week later than this internal build version will include the fix. (This is not always already the next public update.) Please verify that this new version fixes the bug by marking this bug report as VERIFIED after the public update has been released and if you have some time. To answer popular followup questions: * Nokia does not announce release dates of public updates in advance. * There is currently no access to these internal, non-public build versions. A Brainstorm proposal to change this exists at http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/
Setting explicit PR1.2 milestone (so it's clearer in which public release the fix will be available to users). Sorry for the bugmail noise (you can filter on this message).
Now this function does not work at all... There is no reaction and it doesen't matter what I enter. I'll open a new bug and let this one depend on that so we can verify again once the function works again.
Target Milestone should be removed too
(In reply to comment #19) > Now this function does not work at all... There is no reaction and > it doesen't matter what I enter. This was fixed in the HildonTouchSelectorEntry widget, but apparently the browser is not using it anymore. Reassigning bug
Please don't reopen bugs which were marked as fixed in a shipping product.
Restoring resolution. Please note that Uwe filed bug 10535 which can be used as a continuation of this bug.