Add support for escaping the HTML that is inserted in Select option labels

[Kris Zyp]

The Select widget should support the same labelType property as FilteringSelect? and ComboBox?, to escape HTML, in case of user-originated data, to avoid script injection.

[Kris Zyp <kriszyp@…>]

In fe83f7b78b85b115abe9496e47b50f1489dd3e4e/dijit:

Error: Processor CommitTicketReference failed

Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

[Kris Zyp <kriszyp@…>]

In 726cf930426dfab3e252f65cbd5d7626f1e93a25/dijit:

Error: Processor CommitTicketReference failed

Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

[bill]

Kris, all features and bug fixes in dijit need automated tests.

[freddefisk]

Hi! Maybe this is not the correct place to ask this, but I have a question about the plan for this labelType attribute. Will it be a general design for all widgets (like TitlePane?, etc.), only for form widgets or will it be a special thing that only exists for Select, FilteringSelect? and ComboBox??

My concern is that mixing escaping and non-escaping widgets might just be confusing to the developer and will in the end make it harder to write secure code.

[bill]

@freddefisk - I agree things are messed up (i.e. inconsistent) now, but it's impossible to fix w/out breaking backwards compatibility. Too bad.

Although we could add a labelType property to all widgets, I think I'd prefer (for V2) that the label is always interpreted as text. If there's a need to specify a label as HTML then perhaps having two separate properties is better, same way normal Elements have both a textContent and an innerHTML property.

[bill]

Kris added a test in a881dada00fd05ce943940486d9d2b64d86ddcce, closing this, thanks.