We Keep Coding

Is History API consistent across modern browsers?

History API is now supported in every popular browser. It seems there's no need for hash fallbacks, _escaped_fragment_ tricks or other workarounds anymore. Cool libraries from 2013 like History.js seem useless now. But there are some things where I'm not sure - for example title handling seems tricky beacuse apparently title argument in pushState doesn't do anything.
My question is, can I actually rely on the History API to behave consistently across browsers, or do I still need some browser-specific code? This also means: do I need integration tests running in different browsers to test my code then? And if there are inconsistencies, what are they? (Note I'm interested only in modern browsers, so no IE<11).
Maybe someone who implemented routing for a big SPA could share their experience?

Note: This is not a complete answer so I'm not expecting a bounty but it still answers some concerns so I decided to put it as an answer
There are still some differences as with most APIs (you won't believe how inconsistent classList is between browsers); the question is mostly how severe they are.
pushState is most commonly used in SPAs and they seem to ignore the object parameter and mostly handle the URL. This means bugs related to state object handling may be less "visible" to the general public.
The only issue I've recently found that influenced what I was doing is that in IE & Edge (even 14) history.state is a getter so it gets a fresh object instance on every access. This means you can't cache the state object and compare it to history.state to see if a new one was pushed. Here's the bug report: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/944050/
Also, note that no browser supports setting title via pushState and no one ever will, it's too late. If a browser started supporting that, pushState-using sites would suddenly clear all titles in browser history because code is passing empty strings there. You just have to accept that the second parameter is useless.

Actually you can see all the supported browsers by history lib: https://github.com/browserstate/history.js/#browsers-tested-and-working-in
And buglist solved by this lib, from the same page:
HTML5 Browsers
Chrome 8 sometimes does not contain the correct state data when traversing back to the initial state
Safari 5, Safari iOS 4 and Firefox 3 and 4 do not fire the onhashchange event when the page is loaded with a hash
Safari 5 and Safari iOS 4 do not fire the onpopstate event when the hash has changed unlike the other browsers
Safari 5 and Safari iOS 4 fail to return to the correct state once a hash is replaced by a replaceState call / bug report
Safari 5 and Safari iOS 4 sometimes fail to apply the state change under busy conditions / bug report
Google Chrome 8,9,10 and Firefox 4 prior to the RC will always fire onpopstate once the page has loaded / change recommendation
Safari iOS 4.0, 4.1, 4.2 have a working HTML5 History API - although the actual back buttons of the browsers do not work, therefore we treat them as HTML4 browsers
None of the HTML5 browsers actually utilise the title argument to the pushState and replaceState calls
HTML4 Browsers
Old browsers like MSIE 6,7 and Firefox 2 do not have a onhashchange event
MSIE 6 and 7 sometimes do not apply a hash even it was told to (requiring a second call to the apply function)
Non-Opera HTML4 browsers sometimes do not apply the hash when the hash is not urlencoded
All Browsers
State data and titles do not persist once the site is left and then returned (includes page refreshes)
State titles are never applied to the document.title
This might tell you something about existing differences.

There were some issues with History API in Androids before 4 version, but generally it work well across all main browsers.

Selectively Support Certain Browsers

Ok everyone, I have a requirement to only support IE 11+, Chrome 31+, etc. The specifics don't really matter at this point. I know it's not ideal to restrict other browsers, but this is a vendor requirement and isn't my call. I'm just trying to figure out how to go about doing this.
Initially I wanted to use feature detection (my assumption was that the site needed to be HTML5 compatible). These requirements have changed. Is feature detection still viable for this? I would prefer to not use user agent sniffing, since it's so easy to spoof.
I'm using ASP.NET, C#, .NET 4.0, jQuery, HTML5, CSS3
How can I accomplish this?
Thanks in advance!

You can look inside the Request server variable for useful information about the browser. While debugging, it looks to me like this is getting generated from the user agent. From what I know about the web though, this is how clients communicate to servers what they are capable of viewing.
There are a few properties that can help you within Request.Browser.
Request.Browser.Type //Returns "Chrome41"
Request.Browser.Browser // Returns "Chrome"
You could also use conditional comments for IE, something like this:
<!--[if IE 11]>
(Redirect users here or however you want to handle it)
<![endif]-->
I'm sure you've seen these before, but that statement basically is targeting any IE version less than 11. These are Microsoft / IE specific so while this will help you with your IE issue, you will most likely have to rely on the user agent or Request as above for other browsers.

Force Employee To Use Firefox + Specified Version For Company Intranet

Please not not turn this into a discussion about which browser is better and the ethics of forcing a browser. It's an intranet, and it's what I am required to do so everyone calm down =o)
I need to prevent employees from trying to bypass the check to not use their preferred browser instead of the company mandated one + version. The decision was made based on security, compatibility, costs, and the use of company made Firefox extensions.
I came across this Force users to use Chrome/FireFox instead of IE which I can do easily in PHP to force use of Firefox, however it relies on the useragent which can easily be changed in numerous browsers and with the use of plugins.
Is there a JavaScript solution that I can use that DOES NOT check the useragent or any value that can be 'easily' modified by a user/plugin? It would need to detect if the browser is Firefox and what version it is. Site uses jQuery so if it can be done using that, however not required then by all means yes. I just am not aware of what ways to detect a browser and it's version that there are without checking useragent.
I remember way back in the day for detecting Netscape or some browser checking for document.all was used instead of useragent, so I'm guessing something similar, which only Firefox will have.
Thank you very much in advance!

Try this: http://jsfiddle.net/DerekL/62exH/
Because Firefox handles onpopstate differently than other browsers, you can then use this to detect if it is Firefox or not. This can not be changed by user or script. But the disadvantage is you can only get the version number by doing navigator.appVersion.

You can only try but cannot succeed in forcing a browser. That being said you can strip down the CSS in other browsers which may completely make your site close to unusable in other browsers.
To make your CSS only work with Firefox you can try approaches given # Targeting only Firefox with CSS

Best way to display warning message to "untested" browsers?

I have an app that I have fully tested in Safari 5, IE 9, FF6, and Chrome 14. I'm not looking to block or exclude any browsers from the experience. But I want to warn/inform users that there may be a better experience in another browser, and if they choose to continue, there may be features not working or broken.
I have looked at jQuery browser detection, but it seems to be a bit quirky. I know the best solution would be to warn based on feature detection, but we are currently in beta and I am not completely sure what features make or break. Such as web workers, its known that web workers not working breaks our app, but it works in IE lower versions. But then there is an issue with Opera that web workers is available, but not functioning correctly.
Ultimately I am looking for an easy way to say Browser X Version y and up don't show warning, and those and under show warning.
What is the best way to approach this?

Browser detection is indeed "a bit quirky", in pretty much any scenario. The jQuery route is probably as good as you're going to get, but as you say it's not great.
A better solution is generally to do feature detection, especially in cases like the one you describe where your site relies on specific features.
The best feature detection library is Modernizr. This will give you an bunch of Javascript flags which are set to true or false according to whether the browser supports a given feature. It detects support for a whole bunch of stuff, including Web Workers.

Check out this: http://www.w3schools.com/js/js_browser.asp
-Easy way of detecting the user's browser with javascript. From there I'd just use a switch statement or something to display the messages for browsers that aren't tested yet. If you want the exact browser version you'll have to parse it from the "navigator.userAgent" field.

If the goal is full validation, you need to be even more specific about versions. Keep in mind that some browser upgrades are not 100% backwards compatible with previous versions. (Look at how IE8 mode in IE9 is not the same as native IE8 rendering, for instance.) You're going to have to retest with every new browser version, and sooner or later there's going to be a "Fully tested with browser version X, not tested with version X+1 that was released yesterday" problem. Feature detection, graceful degradation, and a warning non-intrusively displayed to the user if their experience is being significantly downgraded is a better way to go.
To directly answer your question, if you must implement what you are asking for just parse the user agent. This could be useful specifically watching out for a browser you know doesn't work right and warning, or as a bandaid for a badly written intranet app that is very picky about the exact browser version it will run on. For a newly developed app where you have control over the requirements, I would not recommend warning on browser version since there are better ways to do it.

AJAX and back button

How can I save history with AJAX just how github or google+ do. I use jQuery and I do not want to use some kind of hack like the # and #! tricks, because if I do, I'll need to change my whole project and make my life much more complicated?

Github and Google+ are using history.pushState.
You can change the current url like this:
history.pushState(null, null, '/the-new-url');
This is supported by Firefox, Chrome, Opera, Safari; not IE.
See https://developer.mozilla.org/en/DOM/Manipulating_the_browser_history#The_pushState%28%29.c2.a0method

There are basically two options when it comes to AJAX and history.
The # method (which isn't a hack btw). Since you don't want that one you only have option 2 left.
Use PushState. This is what Facebook, GitHub and a few others use. It's not supported by all browsers though and if you want complete cross-browser compatibility you will have to use a system which can degrade to option 1.
A very simple way to implement this is Backbone.js Router class.

There is a simple jQuery hashchange plugin that is designed to solve this specific problem.
I haven't used it; I don't know how it keeps track of the url history.