input.value vs. input.getAttribute("value")

Just quick obervation:

HTML comes to client with server side value
"input value='orig'.
Now let's dump
i.value and i.getAttribute("value")
in window.onload handler.

results:
MSIE 7.0: orig, orig
FF: 3.5.6: orig, orig
as expected both values reflect the data sent from server inside value attribute.

Now, change value by typing to "new" text.
Click refresh (or navigate away and back).

You should read "new" in the field (if browser remembers).
All fine:

Now look at the dump from onload handler:

MSIE 7.0: new, new
FF: new, orig

In msie the original HTML markup value is not accessible (lost ?)
by getAttribute after return to the page.

TODO: test the others, find explanation

WebFormViewEngine - how the MVC finds "The View"

Simplified pseudocode: if(useCache) return ViewLocationCache.GetViewLocation(cacheKey) if(IsSpecificPath) //"~" or "/" VirtualPathProvider.FileExists(name); //viewName else if(usingAreas) locations=AreaLocationFormats+LocationFormats else locations=LocationFormats GetPathFromGeneralName(name, controllerName, areaName ,locations) string virtualPath = location.Format(name, controllerName, areaName); VirtualPathProvider.FileExists(virtualPath); So it uses name directly as VirualPath, or tries each virtual path in locations (with or without area specific first) and than tries each. If in cahing mode, returns from cache based on cacheKey. Formats: //{0} - name (viewName), not staring with ~ or / //{1} - controllerName, ControllerContext.RouteData.GetRequiredString("controller"); //{2} - areaName , AreaHelpers.GetAreaName(controllerContext.RouteData); WebFormViewEngine: MasterLocationFormats = new[] { "~/Views/{1}/{0}.master", "~/Views/Shared/{0}.master" }; AreaMasterLocationFormats = new[] { "~/Areas/{2}/Views/{1}/{0}.master", "~/Areas/{2}/Views/Shared/{0}.master", }; ViewLocationFormats = new[] { "~/Views/{1}/{0}.aspx", "~/Views/{1}/{0}.ascx", "~/Views/Shared/{0}.aspx", "~/Views/Shared/{0}.ascx" }; AreaViewLocationFormats = new[] { "~/Areas/{2}/Views/{1}/{0}.aspx", "~/Areas/{2}/Views/{1}/{0}.ascx", "~/Areas/{2}/Views/Shared/{0}.aspx", "~/Areas/{2}/Views/Shared/{0}.ascx", }; PartialViewLocationFormats = ViewLocationFormats; AreaPartialViewLocationFormats = AreaViewLocationFormats; // format is ":ViewCacheEntry:{cacheType}:{prefix}:{name}:{controllerName}:{areaName}:" private const string _cacheKeyFormat = ":ViewCacheEntry:{0}:{1}:{2}:{3}:{4}:"; See MVC source code. P.S. It would be nice to append this inside some poster ;-) Any better explanation links are welcomed.

XHR.onreadystatechange and exceptions

Generally it is not good idea to throw exception in event handler.
However people are lazy and bugs happen, so let's see out chances in this situation.

xhr.onreadystatechange=function(){throw new Error();}


MSIE and FF supports window.onerror event, so uncought exceptions can end up in
this global handler.

All browsers support some sort of "display JavaScript errors" but usually well hidden
as small icon on status bar (MSIE) or deeply in menus (other browsers).

Uniform handling is almost impossible. The very first idea was to rely on
window.error in MSIE an FF and call window.onerror explicitly in
other browsers (even if the browser does not support this error you can define

window.onerror=function...
and call it using window.onerror(msg,..,...) syntax.

However situation is even worse.

1. FF 3.5.6 works fine, ewrror thrown, ends in window.onerror as expected.
   
2. MSIE 7.0 NativeXHR + 200 response - works fine
   
3. MSIE 7.0 NativeXHR + conditional request + 304 response - exception lost, window.onerror not called
   
4. MSIE 7.0 NativeXHR + cached version not tested byt expected - exception lost, window.onerror not called
   
5. FF 3.6 exception lost, window.onerror not called
   

So it seems that we cannot rely:

1. exception being thrown out of boundaries of the handler (eaten exception)
   
2. even if thrown to be catched somewhere (missing window.onerror concept)
   

P.S. tested in async true scenarios, async false can reveal more troubles....