Bug 6099 - (int-123249) Incremental search function is case sensitive for HildonTouchSelectorEntry
(int-123249)
: Incremental search function is case sensitive for HildonTouchSelectorEntry
Status: RESOLVED FIXED
Product: Desktop platform
hildon-widgets
: 5.0/(3.2010.02-8)
: N900 Maemo
: Low normal with 3 votes (vote)
: 5.0/(10.2010.19-1)
Assigned To: Alberto Garcia Gonzalez
: hildon-libs-bugs
: https://bugs.maemo.org/query.cgi?form...
: patch
: int-173498
:
  Show dependency tree
 
Reported: 2009-11-09 20:04 UTC by Uwe Kaminski
Modified: 2010-06-03 19:30 UTC (History)
4 users (show)

See Also:


Attachments
Attachment1 - No incremental search using lower case letters (39.42 KB, image/png)
2009-11-09 20:05 UTC, Uwe Kaminski
Details
Attachment2 - Incremental search works fine using upper case letter at the begin of a string (41.54 KB, image/png)
2009-11-09 20:06 UTC, Uwe Kaminski
Details
Attachment1 - Example for a drop down menu with many list elements on https://bugs.maemo.org/query.cgi?format=advanced (34.78 KB, image/png)
2009-11-09 20:07 UTC, Uwe Kaminski
Details
A possible solution (8.04 KB, patch)
2009-12-09 21:50 UTC, Alberto Garcia Gonzalez
Details
Patch that ignores case and accents (6.87 KB, patch)
2009-12-15 21:19 UTC, Alberto Garcia Gonzalez
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description Uwe Kaminski (reporter) 2009-11-09 20:04:36 UTC
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]).
Comment 1 Uwe Kaminski (reporter) 2009-11-09 20:05:52 UTC
Created an attachment (id=1559) [details]
Attachment1 [details] - No incremental search using lower case letters
Comment 2 Uwe Kaminski (reporter) 2009-11-09 20:06:40 UTC
Created an attachment (id=1560) [details]
Attachment1 [details] - Incremental search works fine using upper case letter at the
begin of a string
Comment 3 Uwe Kaminski (reporter) 2009-11-09 20:07:51 UTC
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
Comment 4 timeless 2009-11-09 22:40:40 UTC
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)?
Comment 5 timeless 2009-11-10 00:16:28 UTC
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.
Comment 6 Uwe Kaminski (reporter) 2009-11-14 20:15:36 UTC
Not fixed in 1.2009.42-11
Comment 7 Alberto Garcia Gonzalez 2009-12-09 20:52:28 UTC
Adding alias of internal bug
Comment 8 Alberto Garcia Gonzalez 2009-12-09 21:32:38 UTC
(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.
Comment 9 Alberto Garcia Gonzalez 2009-12-09 21:50:04 UTC
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.
Comment 10 Alberto Garcia Gonzalez 2009-12-15 21:19:28 UTC
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).
Comment 11 Alberto Garcia Gonzalez 2009-12-16 16:37:33 UTC
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.
Comment 12 Alberto Garcia Gonzalez 2009-12-16 16:39:19 UTC
(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 ;)
Comment 13 Claudio Saavedra 2009-12-16 16:46:48 UTC
(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.
Comment 14 Alberto Garcia Gonzalez 2009-12-16 16:55:17 UTC
(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.
Comment 15 Uwe Kaminski (reporter) 2009-12-26 02:38:35 UTC
Still valid in 1.2009.51-1
Comment 16 Alberto Garcia Gonzalez 2010-01-29 13:00:13 UTC
I've just committed the patch (an updated one):

http://maemo.gitorious.org/hildon/hildon/commit/0d0dc456cbc4f99763c013339aeef84ed6e7758d
Comment 17 Andre Klapper maemo.org 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 maemo.org 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).
Comment 19 Uwe Kaminski (reporter) 2010-06-03 19:07:02 UTC
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.
Comment 20 Uwe Kaminski (reporter) 2010-06-03 19:10:06 UTC
Target Milestone should be removed too
Comment 21 Alberto Garcia Gonzalez 2010-06-03 19:17:49 UTC
(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
Comment 22 timeless 2010-06-03 19:29:33 UTC
Please don't reopen bugs which were marked as fixed in a shipping product.
Comment 23 timeless 2010-06-03 19:30:52 UTC
Restoring resolution.

Please note that Uwe filed bug 10535 which can be used as a continuation of
this bug.