Opened 12 years ago

Closed 12 years ago

Last modified 11 years ago

#11144 closed defect (fixed)

ComboBox: different behaviour with labelFunc and labelAttr

Reported by: richso Owned by: bill
Priority: high Milestone: 1.6
Component: Dijit - Form Version: 1.4.2
Keywords: Cc:
Blocked By: Blocking:

Description (last modified by bill)

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

Attachments (1)

combobox_faultcase.html (2.0 KB) - added by richso 12 years ago.
fault case

Download all attachments as: .zip

Change History (12)

Changed 12 years ago by richso

Attachment: combobox_faultcase.html added

fault case

comment:1 Changed 12 years ago by bill

Description: modified (diff)
Milestone: tbdfuture
Summary: different behaviour with labelFunc and labelAttr in dijit.form.ComboBoxComboBox: different behaviour with labelFunc and labelAttr

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.

comment:2 Changed 12 years ago by 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:


ABC - Song of ABC ABS - Absolute

comment:3 Changed 12 years ago by 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.

comment:4 Changed 12 years ago by bill

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

comment:5 Changed 12 years ago by bill

Milestone: future1.6
Owner: set to bill
Status: newassigned

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.

comment:6 Changed 12 years ago by bill

Resolution: fixed
Status: assignedclosed

(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.

comment:7 Changed 12 years ago by 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.

comment:8 Changed 12 years ago by bill

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

comment:9 Changed 11 years ago by 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.

comment:10 Changed 11 years ago by bill

Same change on 1.6/ branch: [24210]

comment:11 Changed 11 years ago by bill

Component: DijitDijit - Form
Note: See TracTickets for help on using tickets.