ComboBox: different behaviour with labelFunc and labelAttr

[richso]

dijit.form.ComboBox using labelAttr and labelFunc shows different behaviour after selected an option: labelAttr - display the searchAttr value but labelFunc - display the value return from labelFunc, see the attached example

[richso]

fault case

[bill]

Hmm, that's true.

Neither labelAttr or labelFunc work well w/ComboBox (or FilteringSelect). It's a design issue.

labelAttr and labelFunc mostly work to control what markup is displayed in the drop down list, but I think the <input> field needs to display the searchAttr because when the user blurs the ComboBox, then ComboBox tries to do a lookup based on that string in the <input>. But if the <input> field just displays the searchAttr then having a custom label isn't very useful.

So, not sure what to do about this ticket, maybe the ComboBox needs to have two states, marking whether the input contains a label or a search string.

Still, that doesn't allow rich text in the <input> field which is what I was really after in the first place w/this labelAttr/labelFunc feature.

[richso]

IMHO, even that its a design issue, labelAttr and labelFunc should function in the same way, i.e. either both shows the labelAttr / labelFunc return value or searchAttr after selection instead of labelAttr and labelFunc works in different way.

Also, here is some opinion on the design issue: FilteringSelect? and ComboBox? may display the searchAttr side by side with the labelAttr/labelFunc value, if the searchAttr != labelAttr otherwise display only one of them while the user is typing and then display the labelAttr / labelFunc value after the selection, e.g. something like:

---

A

---

ABC - Song of ABC ABS - Absolute

[richso]

Oops ! the 'something like' got scrambled up after save...

The explanation for my opinion on the design issue is that the value from searchAttr should often in shorter form than the value from labelAttr / labelFunc as its to be used for locating the option easier and faster. That should not, in most case, added up the length of the list to be display while the user is typing.

[bill]

(In [22493]) fix tabbing and a typo, refs #11144 !strict.

[bill]

I agree that labelAttr and labelFunc should operate in the same way. Actually what's happening internally is that _announceOption() always calls labelFunc() to get the value to write into the <input> area, but strangely the default implementation of labelFunc() returns searchAttr.

I have no problem making them consistent; I'm just not sure whether the label or the search string should be copied to the input area. But I've got it working with copying the text version of the label (it may be HTML, and of course we don't want to copy tags). So I'll check that in.

[bill]

(In [22539]) If app specifies either labelAttr or labelFunc, when the user selects an entry from the drop down, the <input> text is set to the label's value (a.k.a the text of the entry in the drop down), rather than the searchAttr.

Fixes #11144 !strict.

[bill]

(In [22683]) Fix regression from [22539]. Even when FilteringSelect drop down contains rich text, FilteringSelect.set() shouldn't put markup into the <input> box. Was failing in editor's test_FontChoice.html but I added automated test for FilteringSelect itself. Refs #11144 !strict.

[bill]

(In [22764]) Fix case-sensitivity issue in test file from [22539] (IE reports innerHTML as "<H1>..." not "<h1>..."), refs #11144.

[bill]

(In [24211]) On further consideration, when selecting an item from the drop down list, write searchAttr into the <input> field rather than the label from the selected drop down item. The label in the drop down is by default searchAttr, but can be overridden by specifying labelAttr or labelFunc.

This reverts ComboBox? to the 1.5 behavior when labelAttr is specified, and makes Combox's behavior consistent when labelFunc is specified.

Refs #11144, fixes #12483 on trunk, !strict.

[bill]

Same change on 1.6/ branch: [24210]