We Keep Coding

HtmlButton not running client side validation in IE11

I having an odd issue with a web form using the HTMLButton in asp.net. For formatting reasons i need to use a <button> construct which is fine, it works in every other browser tested but IE11.
<button id="cmdLogin" runat="server" OnServerClick="cmdLogin_OnServerClick" class="btn btn-more" ValidationGroup="Login" CausesValidation="True">
Login
</button>
When i place a standard asp.net button control, it works, the client side validation is run. The difference i can see between the buttons is the onclick function that ASP.Net injects:
if (typeof(Page_ClientValidate) == 'function') Page_ClientValidate('ModalLogin'); __doPostBack('ctl00$scriptsFooterPlaceholder$TDF971800010$cmdLogin','')
I know that IE11 had some issues with __doPostBack .Net 4 for but i am on .Net 4.51, so i don't think it is that. There are no JavaScript errors that i can see that would stop it (and with the standard button test i guess the client side script is working) and in every other browser i have tested (Chrome, FF, Safari, IE8, IE9, IE10) it is working, just IE11.
Anyone seen this sort of issue?

I thought i would try and hijack the click event in IE11 and see if i could manually force the validation. It turned out to be easier as going through the process the code below, "fixes" the IE11 issue:
<script>
var isIE11 = !!navigator.userAgent.match(/Trident.*rv\:11\./);
if (isIE11) {
$('.btn').on('click', function (e) {
e.preventDefault();
});
}
The preventDefault does it, but what is odd is it actually allows the client side validation to work as expected, i.e. it gets caught without forcing a postback (before this the client side stuff was ignored and all forms were validated on postback), so this "fix" is not stopping the client side validation from working.
Note: I do not like or advocate sniffing the browser and version, but in this case as it is only IE11 that has this behavior and i am going to do more research into it after i get this project out the door. It seems like a bug in IE11 with .Net and using the HtmlButton construct which may need a patch from Microsoft.

Name.NameCtrl PresenceEnabled in Visual Studio debug window

I'm using the following code to get contact presence on a web page:
nameCtrl = new ActiveXObject("Name.NameCtrl.1");
if (nameCtrl && nameCtrl.PresenceEnabled) {
presenceEnabled = true;
nameCtrl.OnStatusChange = onPresenceStatusChange;
// ...
}
It works perfectly when I run it in VS but only from a separate Internet Explorer window, doesn't work in the debug IE window started by Visual Studio (so I cannot debug JS code). What happens is that initially nameCtrl.PresenceEnabled is set to true (just after creating ActivexObject) and then is changed to false, I don't get any status updates and all GetStatus calls return 1.
Any ideas how to make it work in Visual Studio?
I'm targeting IE and Lync.

The whole nameCtrl turns out to be very difficult to debug. Some things to check:
If the plugin doesn’t work in IE11, but works if you change the document mode to IE10, it is because IE11 no longer recognizes ActiveXObject as a property of the window object. (see: http://msdn.microsoft.com/en-us/library/ie/dn423948(v=vs.85).aspx).
No javascript errors but nothing seems to be working? For this to work, you may need to go into Internet Explorer’s Internet Options menu and add your domain (or localhost) as a trusted domain.

How to disable pushstate for Chrome? (for Davis.js)

How do you disable pushstate for Chrome (for testing purposes)?
Bonus if you know of a plugin that makes it easy to toggle :)
I'm using davis.js for my pushstate logic.

history.pushState = function (){};
//An empty function so if it is used, it doesn't throw any errors
Put that in the console. Tada! You can easily make a Chrome extension that executes that on a page using a Content Script.

The reason your Davis.js routes are still working is because when you click a link it runs your routes directly, since there is no onPushState event, you should find though that using the back and forward buttons no longer trigger your routes.
If you want to emulate what happens in a browser that doesn't support pushState you can fool around with how Davis.js checks for support. This is done in the Davis.supported function.
You can override that function to always return false, which is what would happen normally in a browser that doesn't support pushState. If you wanted to you could wrap this up into a Davis.js extension, see the block iOS extension as an example.

window.onerror does not work

I have some tricky AJAX code on a form, and sometimes it will fail (don't ask why, I can't get around it). When this happens, I need to trap the error, reset a hidden field indicator, and submit the form naturally so that the user does not have an unpleasant experience. I planned on using window.onerror to do this, but it is never firing! I am using IE8 and all I have to worry about is the IE browser. Is there some gotcha to getting this event to work? Here's my code...
window.onerror = function() {
alert("Error!");
document.getElementById("hidAjax").value = "0";
document.forms[0].submit();
}

"A common problem that bites many developers occurs when their onerror handler is not called because they have script debugging enabled for Internet Explorer. This will be the case by default if you have installed the Microsoft Script Debugger or Microsoft Visual Studio 6.0® (specifically Visual InterDev 6.0™)—onerror handling is how these products launch their debugger. You can disable script debugging for a given instance of Internet Explorer on the Advanced tab of the Internet Options dialog box (note that checking the Disable script debugging setting will apply only to that instance of Internet Explorer):"
http://msdn.microsoft.com/en-us/library/ms976144.aspx

try/catch also introduces an additional error object that only has the scope of the catch. In applications where performance matters, this is not a good idea.

Any reason not to just put a try/catch around the tricky code?

How do I add an alert when the user tries to press the back button or is using firefox? (Javascript)

Just need a little bit of Javascript to warn people that press the back button that it might screw up their transaction with an Ok/Cancel button, and also a way of detecting if they are using any version of firefox.

You could use something like http://www.sajithmr.me/warning-before-navigate-away-from-a-page/ in order to check if a user is about to leave the page. I'm not sure if there is a solution to target the back-button specifically.

As to your browser detection question, I don't really like using user agent based browser detection, its better to do feature testing onLoad. But if you are just looking to see if someone is using (or says they are using) Firefox, you can parse the useragent string. Here is an example of this from the jQuery 1.3.2 source:
var userAgent = navigator.userAgent.toLowerCase();
// Figure out what browser is being used
jQuery.browser = {
version: (userAgent.match( /.+(?:rv|it|ra|ie)[\/: ]([\d.]+)/ ) || [0,'0'])[1],
safari: /webkit/.test( userAgent ),
opera: /opera/.test( userAgent ),
msie: /msie/.test( userAgent ) && !/opera/.test( userAgent ),
mozilla: /mozilla/.test( userAgent ) && !/(compatible|webkit)/.test( userAgent )
};

This SO question: Detecting Back Button/Hash Change in URL will answer most of your question.
Detecting the back button is a tricky business because it's the same behaviour as closing the window.
You can use the onbeforeunload event handler to handle this but like i say, it's a bit tricky.

Both back-breaking and UA-sniffing are a huge code smell.
A properly-coded web application should not “screw up” when the user goes back a step in a transaction. If it does, you probably have a collection of concurrency problems which will make your site unpleasant to use.
UA-sniffing is highly troublesome, prone to false positives and negatives and, if done on the server end, proxy problems. What is the reason you want to detect Firefox? If you are trying to work around a particular Firefox problem there is almost certainly a better approach focusing on that one feature rather than trying to detect a particular browser.