Sorting issue (FF20/IE10) with the value map of RadioGroupItem

[mpretorian]

Hi Isomorphic,

We have an issue with the sorted map for RadioGroupItem. We reproduced it in the Showcase from the nightly build 3.1p-26.06.2013. Attached is the adjusted class FormVariousControlsSample.

Firefox 20.0.1 result: radio buttons are ordered from AAA to FFF
Internet Explorer 10 result: radio buttons are ordered from FFF to AAA .

From our perspective FFs result is right.
Could you please explain that difference?

Thanks
PS: Here is a similar thread: http://forums.smartclient.com/showthread.php?t=13613

[mpretorian]

Any news on this issue?

[Isomorphic]

It's being looked at

[Isomorphic]

This behavior is being caused by a change introduced in IE9 (and Chrome) where for..in iteration over a JavaScript object, the order of iteration over properties no longer follows the order of declaration, but *only* for properties that happen to be parsable as positive integers.

Yes, this is very surprising and inconsistent. We were very vocal in protesting against this change.

The easiest workaround is to introduce any other character into the property name. A trailing space (like "0 ") would work, for example.

This may require some additional parsing logic to trim off the trailing space at a later stage, but this is the least bad of all of the workarounds for this bizarre browser behavior.

[Blama]

Hi Isomorphic,

it seems that FF also shows this behaviour.

leadTypeRGI = new RadioGroupItem() {
					{
						setColSpan("*");
						setRequired(true);
						setVertical(false);
						LinkedHashMap<Integer, String> optionMap = new LinkedHashMap<Integer, String>();
						SettingsCache sc = SettingsCache.getInstance();
						for (Integer i = 1; i <= 8; i++) {
							Integer selectionEntryId = sc.getIntSetting(sc.getStringSetting("leadStatusNo" + i.toString()) + "_id");
							String selectionEntryName = sc.getStringSetting(sc.getStringSetting("leadStatusNo" + i.toString())
									+ "_name");
							SC.say(i.toString() + ": " + selectionEntryName + " (id " + selectionEntryId.toString() + ")");
							optionMap.put(selectionEntryId, selectionEntryName);
						}
						setValueMap(optionMap);
						setRedrawOnChange(true);
					}
				};

The FormItem on the screen shows the entries sorted by "selectionEntryId" (which is a positive integer), not in the order of insert into the LinkedHashMap.
I'm using v9.0p_2013-10-15/EVAL Deployment and tested with FF24.0 and Chrome.

(Sidenote: The SC.say() seems to be executed only for the last (of 8) item, I get only one messagebox. Is that correct or a timing related bug).

Any upcoming changes on that issue or stick to the suggested workaround?

Thanks,
Blama