Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#16452 closed defect (fixed)

security exceptions setting name through innerHTML (Windows 8 apps)

Reported by: Paul Christopher Owned by: bill
Priority: undecided Milestone: 1.9
Component: Dijit Version: 1.8.1
Keywords: Cc:
Blocked By: Blocking:


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", ...).

Change History (7)

comment:1 Changed 9 years ago by bill

Reporter: changed from bill to Paul Christopher

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.

comment:2 Changed 9 years ago by bill

Milestone: tbd1.9
Status: newassigned

comment:3 Changed 9 years ago by bill

Resolution: fixed
Status: assignedclosed

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.

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

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

comment:6 Changed 9 years ago by bill

In [30418]:

fix tabbing, refs #16452 !strict

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

Note: See TracTickets for help on using tickets.