We Keep Coding

SetInterval is not working in Kindle and Kobo Browsers

I want do stream images to my e-ink reader's browser. I have a Kobo Aura H2O and a Kindle Paperwhite.
I have tried multiple mechanics but nothing seems to work, because the browser ignores half of the javascript.
Websockets do not work, setInterval to update the image regularly does not work neither
Are there any Specs of this Browsers to be found? What other alternatives within Javascript are there to test?

The Kindle browser does technically support WebSockets (even on the very first Kindle Touch), however because it's based on a very old version of Webkit, it's the very first version (or one of the first versions, I'm not exactly sure) of the WebSocket spec which is very different from the current one and isn't supported in the majority of Websocket libraries.
I made a very bad patch for the Node ws library here: https://github.com/HimbeersaftLP/ws
Google's pywebsocket also supports it: https://github.com/google/pywebsocket/wiki/WebSocketProtocolSpec

setInterval actually works, the problem was that I have used es6 instead of es5 js syntax.
Websockets also work with Kobo Browser but not on Kindle

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.

Cons of using Internet Explorer's Compatibility Mode

What are cons of force a web site viewed in IE to compatible mode? Say we force IE9 to IE8 compatiblity mode?
Performance drawbacks
Can't use any new IE9 specific features like HTML5/CSS3/SVG
Why?
We run legacy web app which is developed since 2000 so it's a mess ball fighting to be compatible with Chrome, Opera, Firefox, IE6/7/8 and now we decide to add IE9 to the list. But with IE9 we run in issues with printing, "Permission deniend" JavaScript errors (probably something about cross-frame JavaScript calls) and next issues - the easy workaround is to force IE9 to behave as a IE8 and then everything works fine. But I am still not sure if it's way to go...

first our app is public site (for our clients)
You have a public website developed in 2000 and it doesn't work on modern browsers? Deprecate it or re-write it.
Don't hack your code to support modern browsers, the website is clearly poorly written and doesn't apply to standards. You can't get away with this.
The only place where you can get away with this level of incompatibility is intranet applications and even then you should simply state "it works on browser X, live with it"
You can't say that to public facing clients. I mean you can try, but have fun losing business to your competitors.
Re-develop your website to match the W3C HTML/CSS standards and the ES5 standards and it will be completely future facing (for some years).
Alas, the way the web works is that anything more then 5 years old is deprecated. So either re-write it every 5 years or get out of the web business.
In terms of actually using compatibility mode, don't. IE6-8 are horrible engines and should be avoided like the plague. If you use them then you can't write future facing standards compliant code.
Your code needs to match the standards and you should fix / shim / patch any browser specific bugs where those browsers don't implement the standards.

You cannot say you have tested in IE6/7/8/9 until you have tested in those different versions. Emulating the test environment is not the same as using the test environment. To my knowledge IE7/8 compatibility modes are the older render engines, not the underlying browser as a whole, bugs and all. It is closed source so you will never know.
Convert Microsoft's free to download virtual disk images for cross-browser testing to Virtualbox images and put them on a machine that just runs Virtualbox. An old machine will do, run the VMs headless and access them with remote desktop. In that way you will be able to test in all browsers without burdening your machine with MS/Spyware.

I believe your system admins can set IE to compatibility mode for all intranet traffic using the Group Policy Editor. Any site you create will from this point forward, you can add a meta tag to force IE9 to render natively and use all the newer features...
I'm having to do that on my current project using the following doctype and meta tag in my header:
<!DOCTYPE HTML >
<meta http-equiv="X-UA-Compatible" content="IE=100" />

Compatability mode is something that MS introduced to give people some chance to upgrade their applications, not for long term use. AFAIU.
If you want your application to be compatible with IE9, then you will have to change it. If you are trying to maintain IE6-9 compatibility then you have a real challenge, and you should consider whether this is really practical - in essence, you need at least 2 distinct sets of html. Is this practical for you?
IE9 compatibility mode is different form IE9 and IE8 - it draws bits from both. So you need to do a full test agaisnt the compatibility mode version, and ensure that it remains working against this.
So in answer to the question, the cons are that you are not being IE9 compatible, and there is a danger that when IE10 comes out, your code will not run against that in any mode. You are putting the effort into compatibilty testing without providing for future changes. You would do better, in the longer term, to make your code IE9 compatible. Also, the message you are giving your clients is that your code base is not going to be compatible for much longer. Unless you are talking to them about a re-work, this is a real negative.
However, it sounds like your entire code needs a re-work, to forget about IE6 and be written for modern working browsers. Using compatibility mode until that happens is probably OK. If you do this - and tell your clients - then staying in compatibility mode is viable.

Using compatibility mode will NOT cause the browser to use the JavaScript engine that was present in the old version of IE.
By that I mean it will run any JavaScript code using the IE9 engine. Which was a problem for us when debugging an old product that had a problem with IE7/8.

Any serious problems when making an old java web app run on new IE 8 browser?

I need make an quick estimation on project (not sure we got):
It's an old banking CMS java web app, but the UI aimed for getting near the winform style:
Server: jdk5, weblogic 9 (JSP 1.x), only use weblogic internal servlet (not strut...).
Client: winXP, Ie6.
It was design only for use with ie6 but now we need make it also run well on new client: ie8,ie7 on win7. I understand the most difference is the client: DOM and CSS.
But my problem is we hasn't been worked with ie8, and I have not enough time to build an testing environment because our developing environment is not ready to make test (its remoting completely, and managed by another partner)
Any experience or suggestion to help me weighing this task need will be welcomed.
Edit: HTML, CSS is fairy outdated, not work on firefox at all, JS is barely procedure, no ajax, no plugins.
Client PC is limited for banking and, internal use (user not be supposed to change config or choose the browser)
Using activeX to manipulating printer and creating the report (increase ability to meet security problem )

This has nothing to do with Java, or weblogic. What you need to worry is javascript and css.
As long as your concern is limited to IE7 and IE8 only (ignoring Firefox, Chrome, etc), I think you are pretty safe. These two browsers have compatibility mode that should work with IE6 designed websites. Most problem would probably cosmetic rather than functions.

In my eyes, this is going to be impossible to tell without actually testing the application.
It'll totally depend on what kind of markup was used. Possible problems can range from near zero (if only standard markup, simple design, and basic Javascript or a framework like jQuery was used) to several weeks of fixing (heavy use of complex CSS rules optimized for IE6; heavy use of IE specific Javascript).

I'm not sure about any DOM problems since IE8 hasn't had any significant DOM updates since 1998 while any other browser is far more advanced than that. CSS and, maybe, javascript will be the big issue since you say it doesn't work in any modern browser (Firefox, Chrome, etc.)

Browser compatibility; Before or after uploading website to server?

I am on the stage where I need to make my website cross-browser compatible.
I need tips on how to get started.
I have developed my website on firefox, so it works great with firefox.
I guess I have to download a couple of versions of all major browsers now, right?
Then just test each browser one by one?
Should I do this before uploading the entire website onto a server or afterwards?
All tips and SW which makes this easier is appreciated.
BTW, it is a classifieds website using MySql, Solr, PHP, js etc...
Thanks

Cross-browser compatibility is best planned for in advance, as there are ways to build your site that will make it much easier.
Consider using a CSS reset script like Eric Meyer's.
Consider using a JavaScript library like jQuery.
You can make use of Adobe BrowserLab to do cross-browser testing.
Consider the mobile audience.

You need to have some kind of local webserver so you can edit the code and test it in a comfortable way. It is also helpful if you make it accessible for validator.w3.org so you can do syntax checking.
Testing it in IE6, 7 and 8, Firefox and Chrome would be a good start I would say.

Since you are working with server side code, you need to have a server.
Once the site goes live you will need both a live and a development server.

Yes, I'd make it cross browser compatible before uploading to the server. The reason for this is that you may need to change the server-side code, adding ids and classes to the markup, plus it may well be necessary to change the markup. Make sure it's working locally first.
IE Tester is very useful for testing on the various IE browsers. I'd ensure that I've tested it on a Webkit browser (such as Chrome), a Gecko Browser (such as Firefox) and Opera. See this list for different browsers.