security exceptions setting name through innerHTML (Windows 8 apps)

[Paul Christopher]

Broken off from #16432...

Windows 8 applications by default throw exceptions when the app tries to create a DOMNode with the name attribute via assignment to innerHTML, i.e.:

foo.innerHTML = "<input name=bar>";

This bites dijit in two (known) places:

• MappedTextBox
• the templates for the form widgets that don't extend MappedTextBox, that contain the ${nameAttrSetting} substitution variable.

The irony is that we are setting the "name" attribute through innerHTML, rather than saying node.setAttribute("name", ...), to workaround bugs in old versions of IE (IE6 and IE7 IIRC).

The solution is to either use MSApp.execUnsafeLocalFunction(), or to to use node.setAttribute("name", ...).

[bill]

BTW Paul, you shouldn't have made a username with spaces in it, it apparently ​stops you from being CC'd on tickets. I marked #16451 and this ticket from you though since they are based on your original ticket.

[bill]

In [30156]:

Windows 8 Store Apps throw an exception when trying to set an element's name attribute via innerHTML. So avoid doing that on Windows 8 Apps. Instead, do it via the _setNameAttr custom setter. This is how it should be done for all platforms starting in 2.0.

Old code to set name via innerHTML was left in place for supporting the older versions of IE (refs #8660, #8484). Also, this.nameAttrSetting needs to be remain until 2.0 for backwards compatibility, because custom widgets may be referencing it in their templates.

Changes were tested locally on firefox by changing the conditions in _FormWidget.js and MappedTextBox.js from !has("win8app") to has("ie").

Fixes #16452 !strict.

[cjolif]

This commit is breaking applications that set name="something" on widgets that are inheriting from Button but do not have a valueNode. They now throw an exception they did not throw before (it seems from previous code valueNode used to be optional, it is not anymore). See my comment on this other ticket:

​http://bugs.dojotoolkit.org/ticket/16580#comment:4

[bill]

OK, understood. I'll add workaround code in Button just so people don't claim that dojo is broken, although if there are widgets that extended Button and yet don't specify a value node, it really seems like an error in those classes. In other words, whenever you subclass a widget you need to specify all the attach-points that the original widget had, and I don't see why Button should be different just because it didn't used to cause an exception.

[bill]

In [30418]:

fix tabbing, refs #16452 !strict

[bill]

In [30423]:

In order to avoid breaking existing code, avoid exception on creation of Button subclasses if this.valueNode is not defined. Refs #16452 !strict.