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

Comment 17 Andre Klapper 2010-02-17 21:16:25 UTC

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/

Comment 18 Andre Klapper 2010-03-15 20:54:03 UTC

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.