Hi Divyan, It looks like the problem lies here: https://github.com/mootools/mootools-core/blob/master/Source/Element/Element.js#L846. Essentially, it looks as though you're moving into the "adopt" codepath, rather than a simple .innerHTML codepath.
What's happening is that MooTools is grabbing your elements, injecting them into a temporary element (with .innerHTML), then adopting the children of that temporary element into the original element. As you can see in http://jsfiddle.net/barryvan/PeXkq/ , in Fx, this results in the final element that's injected being selected. There are a couple of ways to work around this. You could do what you're already doing -- just using ".innerHTML" directly. Alternatively, you could go down the path of creating your own wrapper element, figuring out which item is selected, injecting the options into the correct select, then setting the selected item again, but that seems like overkill to me. My personal preference would be to have the data returned as JSON, which is then turned into option elements that are injected into the select. I'm not quite sure why MooTools does this -- I can understand that tables (with the whole tbody/thead/tfoot malarkey) could require some massaging, but I'm not sure why selects also need special treatment. Perhaps one of the devs can enlighten us. :) Personally, I would consider this behaviour buggy -- it's certainly not what's expected, in my opinion! Barry van Oudtshoorn http://barryvan.com.au/ [email protected] On Mon, Jul 4, 2011 at 7:24 PM, Divyan <[email protected]> wrote: > I noticed a little inconstancy with the Element.set() method. > > If you look at the example below in Firefox (Chrome does what it > should do and IE9 doesn't even work ;-) ) you'll see that the 3rd > Testoption should be the selected one, but this isn't happening. > > http://jsfiddle.net/Lktfw/1/ > > Is this a bug, or is it done wrong by me?
