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
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
The calendar element is selected.
nothing happens (see Attachment1 [details]). If you try step 4 writing calendar like
"Calendar" it works correctly (see Attachment2 [details]).
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:
there is a drop-down menu with a lot of list items to reproduce this issue (See
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
yep, we know.
this is actually a rat's nest.
this isn't an excuse, but it's an exercise:
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,
Address book is case insensitive, stop character challenged, and accent
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
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
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
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
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
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
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
(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):
This has been fixed in package
which is part of the internal build version
(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
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
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.
Please don't reopen bugs which were marked as fixed in a shipping product.
Please note that Uwe filed bug 10535 which can be used as a continuation of