Here is a patch to move the code to setup the store from startup to postCreate, I also removed the odd connect call for _loadChildren and moved that call into startup. It solves this problem, and all of the dijit form tests related to select passed.

It looks like the 2nd problem is in _patches.js, it is calling this._dbstartup(), but it should be checking to be sure that this._dbstartup is not undefined before calling it.
For some reason the _DataBindingMixin which has the _dbstartup function is not being mixed into dijit.form._SelectMenu.
This seems to fix the 2nd problem:

if(this._dbstartup){

this._dbstartup();

}

I will try to figure out why the initial value is not getting set correctly tomorrow.

that will stop the errors but i'm not sure it fixes the problem. all widgets derived from dijit._WidgetBase should have _dbstartup after the patches are applied. the problem is that in this case we have a widget that doesn't have _dbstartup which will lead to failures due to the widget not binding to its parent.

it smells like there's something strange with the inheritance chain. i'll let you know if i can find anything.

I agree, the check stops the error and allows the drop-down to display, but we do need to find the inheritance problem. I have not been able to figure it out yet, but interestingly FilteringSelect? does not have either problem. I suspect that if we fix the inheritance problem it will fix both problems.

i've spent a few hours looking at it and i can't figure out why it's different but anything derived from dijit._MenuBase does not get affected by the patches. it's also possible that there are other classes besides dijit._MenuBase where this is happening.

i know that dojo.declare resolves inheritance chains in a specific way that means that cases can exist where updating the prototype of a superclass doesn't affect the subclasses as would normally happen with prototypical inheritance. afaik, only one class in the chain is truly a superclass and the rest are all copied/mixed in. anyone familiar with c3mro? i understand the concept but when it comes to analyzing why its causing this specific problem it's beyond my current understanding.

given how dojo.declare works, i had realized that it would be possible that classes might exist that wouldn't be affected by the patches. however, the only alternative to extending the dijit._WidgetBase prototype is to take a different approach where the user needs to explicitly mixin a class to every class that they want to use with mvc. i know that's not at all desirable.

i copied eugene since he wrote the current version of dojo.declare and maybe he can explain what it is about dijit._MenuBase that causes it (and its subclasses) to become "detached" from the dijit._WidgetBase prototype.

PS: although the above problem should be fixed, it's probably unrelated to the MVC/Select issue. Because I've also noticed a failure in dijit/themes/themeTester-orig.html on IE6 where the root cause is that MenuBar doesn't inherit the layoutPriority flag created in a dojo.extend(). Mailed Eugene about it a while ago; it happens without MVC.

Yes, the overcomplication has been mentioned, I didn't get around to reply to it. The basis for that pattern is to indicate that _DataBindingMixin is a potential unit of reuse. At this point the only thing we're extending is _WidgetBase, though any other widget or library (custom) that provides a dojo.Stateful contract as dijit does may, in theory, be extended similarly and thereby become a data-bound widget in the dojox.mvc sense.

sorry for the noise... one more thing to note. the 13372-c3mro.html file represents what the classes would look like if the patch in comment:10 was applied. to see the state of the classes without that patch, swap the order of the G and H dependencies in the declaration of the D class.

i'm fairly certain its not a bug of dojo.declare - its the way it is supposed to work. eugene might be able to shed some more light but see ​http://www.python.org/download/releases/2.3/mro/ - it was a lot for me to understand in depth and is why i attached the debugging files that helped me. if you don't have the time to spend to get a deep understanding of it (it took me a day and a half of debugging to come up with this patch) then take my word that there is no bug with dojo.declare.

by luck more than by design changing the dijit._WidgetBase prototype will affect subclasses. however, using c3mro this is not a given. before eugene refactored dojo.declare to use c3mro, it was my understanding that the prototype chain was kept in tact (multiple inheritance) but with c3mro the prototype chain is not guaranteed to be preserved (single inheritance). i opened #10788 at the time when i started to observe some unexpected changes in behavior but based on the discussion in that ticket i became aware that c3mro uses single inheritance and mixes in the other classes (see ​http://bugs.dojotoolkit.org/ticket/10788#comment:13) such that a situation could be possible where dijit._WidgetBase may be mixed in rather than part of the prototype chain.

the declaration order in _KeyNavContainer dictates that properties from _Container should be overriden by _FocusMixin properties. _Widget is declared in such a way that properties from _FocusMixin should override _WidgetBase. in _MenuBase this leads to the following linearization:

this makes dijit._Widget the superclass and only _TemplatedMixin, _Container, _KeyNavContainer and _MenuBase are mixed in because the rest of the linearization after dijit._Widget matches the linearization for dijit._Widget.

i expect that this may not be easy to understand (a week ago i would have not seen the problem) but the bottom line is that dojo.declare does not have a bug and if you want subclasses of dijit._MenuBase to reflect changes to the prototype of dijit._WidgetBase then apply the patch. its a harmless change because _FocusMixin and _Container do not have any overlapping properties so apart from this inheritance chain, there is no difference in which order they are applied. given how the c3mro linearization works my real surprise is that we never saw something like this earlier.

Wow, so _WidgetBase was getting mixed in rather than being inherited. Thanks for tracking that down. Yes, the change you suggested fixes the Menu problem too. I'll check it in with a test case for that Menu problem. Someone should add a test to the MVC code for dijit.form.Select.

(In [25769]) Fix inheritance chain so that _WidgetBase is (prototypically) inherited by widgets, rather than being a mixin. Thanks to Ben for tracking all this down and the patch. Fixes #13372 !strict.

Ben, are you getting the initial value set correctly now?
I am still seeing the first problem "the initial value of the select is not set to the value represented by ref". But the update does fix the second problem.
I will add an MVC test for dijit.form.Select.

ed, you beat me to it... the initial problem still exists so i'll reopen this ticket since that was the main problem. in addition to the test for dijit.form.Select it would probably be good to add tests for all widgets with values. this would be all of dijit.form as well as dijit.Calendar, dijit.Editor, ...? i think most of the existing tests only use some form of TextBox?.

Ed, thanks for offering to write up the test. It'd be great if you could make that test a kitchen sink test for all form dijits, that'll give us full test coverage and identify all that need working through.

I am finally able to get back to working on this, and I am looking for suggestions on how to handle this problem. The problem with the setting of the initial value is that there is a race condition where the value gets set to 1 by the _DataBindingMixin (line 281) for the ref, but that value is overwritten to 8 in _FormSelectWidget line 271 in the onComplete: function.

That does look dodgy, I don't know why it's setting the store so late, That setStore() function is tricky since it takes a number of arguments, but sure seems like the setStore() code in startup() could be moved to postCreate().

After talking to Doug about this, we decided to remove my patch which had this comment:
("I tried Bill's suggestion to move the store setup from startup to postCreate, and it did fix the problem. It also passed all of the dijit form tests. Here is the patch. ")
pending a little more investigation.

Doug was concerned about an async load case for the store, but it turns out that the async load case is not a problem, since this._loadingStore gets set true before the mvc code tries to set the value, so code in _setValueAttr will save the value away in this._pendingValue and use it when the store load is complete if this._loadingStore is true.

Another fix for this problem would be to change _FormSelectWidget's startup function to call this.inherited(arguments); at the end instead of the beginning, this would have the mvc code run after this._loadingStore is set true, and it may be a safer change.
I was able to successfully run all of the dijit.form tests with this change, and I ran some of the related dojox.form tests.

Doug also had a question about why postCreate was calling:
this.connect(this, "startup", "_loadChildren");

I did not see a difference with or without this connection setup in the tests, but I did see that the _loadChildren being called was the one in dijit.form.Select, and that the one in _FormSelectWidget was not called unless the drop-down is displayed, because _loadChildren in Select checks if(loadMenuItems === true)before it calls this.inherited(arguments);

Doug and I also talked about waiting on this fix until after 1.7, if we are close to shipping dojo 1.7, we may want to wait on making this fix since it is not a major problem. We can fix it in 1.8.

I added the kitchen sink tests along with other updates via this changeset: In [26567] which was made for ticket #13773. But this ticket should remain open until the initialization of the dijit.form.Select is fixed. There is a test in the kitchensink test dealing with the initial setting of the dijit.form.Select which I have commented out for now. Once this is fixed that test should be uncommented.

Here is a patch to move the code to setup the store from startup to postCreate, I also removed the odd connect call for _loadChildren and moved that call into startup. It solves this problem, and all of the dijit form tests related to select passed.