I am supporting a vb.net 2010 web form .net application and I have found out that some of the JavaScript has been deprecated using Internet Explorer by using the Internet Explorer web developer tools. I have now used the Firefox browser and the application seems to work for what I have tested so far.
Before I place the new version of the application into production, I would like to know what JavaScript features are currently obsolete and/or may be deprecated in the near future.
Due to that fact, would you tell me and/or point me to urls (links) that will tell me what JavaScript items are obsolete and/or deprecated using the Firefox browser?
Related
I am using PhantomJS (headless end to end testing),selenium webdriver,grunt(task runner) for my application testing. My requirement is that the application should be compatible with IE-9. I have to do headless testing because I'm using jenkins for continuous integration.
How do i make sure that my application will run perfectly on IE-9
while testing on phantomJS ?
You can't use PhantomJS for testing compatibility with Internet Explorer, because it is a Webkit browser.
Since you're using Selenium, you should be able to use the IE WebDriver.
Some thoughts on why you can't even simulate IE in PhantomJS:
They are built on different base technologies. They use different rendering engines and both have different bugs when it comes to adhering to W3C specifications.
JavaScript bugs may be simulatable, but this requires you to go ahead and fix all bugs that PhantomJS has in comparison to your specific IE version by exchanging the implementation of some browser APIs. You would also need to introduce some bugs that are present in your IE version, but not in PhantomJS again by exchanging implementation.
CSS bugs can only be introduced if you change the WebKit implementation and compile it again. You would have to find them first.
Great, you have effectively reverse engineered IE.
Our current development is in VS 2008 using WebForms and JQuery. We must support IE8.
For new projects I would like to start using VS 2013/MVC but I am not sure if support of IE8 will be an issue. I have used VS 2013 for short time on co-worker's PC and I noticed it includes JQuery, Bootstrap, modernizr-2.6.2.js and respond.js frameworks (of those I am only a bit familiar with JQuery) in project generated from MVC template. Note that I am fairly new to web development and JavaScript in particular.
JQuery used in this project is version 1.10.2 and 1.* JQuery branch supports IE8.
Bootstrap is v. 3.0.0 and IE8 support has some limitations as I found here: http://getbootstrap.com/getting-started/#support Are these a big deal/show stoppers? Are there workarounds?
Information I found on modernizr is not completely clear. On one hand this page http://modernizr.com/docs/ says: "We support IE6+, Firefox 3.5+, Opera 9.6+, Safari 2+, Chrome.". On the other hand the same page says: "If you don't support IE8 and don't need to worry about FOUC, feel free to include modernizr.js whereever."
As far as respond.js it seems there are some issues for which people usually find workarounds.
Are there any issues inherent to latest version of MVC itself (other than JavaScript component compatibility) that make it incompatible with IE8?
ASP.NET MVC 5 itself should not have any compatibility issues with IE8. The Javascript libraries might have issues, but that depends on the developer.
By using VS2013/MVC and their project template, you're not required to use Bootstrap, Modernizr or whatever they include. If you don't need it, you can just remove the references. You can also manually add-in an older version of the libraries, if they do support IE8.
It was possible to sign with digital certificate in IE and Netscape
http://bozhobg.wordpress.com/2009/04/16/how-to-create-a-digital-signing-solution-with-only-javascript/
What's the equivalent in IE 9 ?
You're going to have a problem with this.
The clue is in the code in the link you provided. Specifically, where it uses new ActiveXObject().
ActiveX is a very old technology and it has severe security issues. For this reason, it's use has been discouraged for some time (this was the case a long time before the article you linked to was written).
IE9 does still support it, but only for legacy reasons; its use is strongly discouraged, and you will need to go to the browser config and disable some security settings in order to get it working.
If you do get activeX working in IE9, you'll also need to make sure you have the relevant activeX controls installed on your PC that actually do the work (I've not used the ones in question, so I can't advise on them). In addition, since the activeX technology is deprecated, you may find that the activeX control you need to use may not have been kept up-to-date. This may affect whether it works with newer versions of IE or Windows.
I am getting a very weird kind of error with IE9. When I use a DOMParser from within a jsp page on localhost, it runs perfectly fine and gives the proper result.
But Shockingly, when I use DOMParser inside a normal HTML file (Not on the server. From the file system), I get this annoying message of "DOMParser is undefined" .. What is this and how can I make it work? Thank You.
P.S. It works fine on FF and Chrome
I would say that this is almost certain to be the browser running in compatibility mode when browsing local URLs.
You can check this by opening the dev tools (press F12) and looking in the top right corner; if it says it's in IE7 mode, then you've found the problem. Switch it back to normal IE9 mode and it should come right.
IE7 didn't support the DomParser object, so if IE9 is in IE7 compatibility mode, it's natural that it will stop supporting it too.
Ok, so that's what it's doing. But why is it doing this? There is a config setting in IE (both IE8 and IE9) which specifies that the browser should fall into compatibility mode when browsing sites on the local intranet. The reason for this setting existing is to allow companies who have internal sites designed for older versions of IE to upgrade to a new version without breaking those sites. It's intended to make like easier for corporate types who would rather not spend money fixing something when the broken version is good enough.
But it's a pain in the rear for the rest of us.
Obviously, if your site is on the public internet, it won't be affected by this flag, except when you're trying to work on it from localhost on your own PC. Therefore, the solution for you is to simply turn off this config setting in the browser and forget about it.
Of course, the fact remains that users of IE7 will still have this problem with your site, as their browser doesn't support the feature you're using. You could just drop support for IE7, and tell those users to upgrade. But if you want to support IE7 users, I believe that Dean Edwards' IE7.js script allows the browser to emulate this feature (along with a bunch of other stuff that Microsoft forgot).
Hope that helps.
I received this error, "DOMParser is undefined", on IE9 and it turned out to be an add-on that was disabled.
Name XML DOM Document
Publisher Microsoft Corporation
Status Enabled
Tools – Manage Add-ons – Microsoft Corporation
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.