Slashdot Mirror
Migrating IE Web Apps to Mozilla
PabloHoffman writes "Have you ever wondered what would it take to make your (unfortunately) IE-only web app to work on Firefox?. IBM published an interesting article about migrating Internet Explorer specific web applications to Mozilla-based browers. It covers basic cross-browser development techniques, and some developing strategies for overcoming the differences between both browsers."
If you want to hear about my own personal attempt to migrate the company webapp to firefox. Haha.
I often have to make my apps work in both, simply because I find the Firefox DOM inspector to be indispensable for tracking down screwey CSS behavior. It really hasn't been that tough to make the apps work in both IMHO.
IE has some advantages for businesses that have already standardized on using Windows, but for companies that aren't diehard supporters, why bother? The "debugger in IE," if you can even call it a debugger at all, is horrible as is the browser in general these days.
.NET development when you have free access to Visual Studio.
Any sane company that doesn't need the IE-specific features would be insane to not build on Mozilla with its excellent debugging tools and then test with standards-compliant browsers like Opera and then test with IE. IMO, build on IE first instead of using Firefox or Mozilla is akin to using Notepad and nAnt for Windows
Click here or a puppy gets stomped!
some of the code examples show how to make it browser-independent and specifically show cases and code for allowing Netscape, Firefox, and Opera all to work with previously IE-specific code.
But, in general, it's a fairly good doc.
I enjoy the part about not sniffing the useragent to make it version specific when that may make it so that you have to upgrade the code when a new version comes out, even though the behaviour hasn't changed - which means less revisions just for incrementalism, and more revisions for functional changes.
-- Tigger warning: This post may contain tiggers! --
I find it interesting that an article about creating cross browser web pages does not print out properly from Firefox. The right side of some text gets cut off.
Sig free since 2/6/2002
Right! Web applications should be thought of as three tiered client server appications. As such, any processing you can do client side, should be done there. It makes no sense to wait until the data has been sent to the server to throw an error for a required field. The client knows whether the field is NULL or not. Why should I make the sever process this. Besides, passing processing off to the client makes the entire application more robust. There is only one server, but there is an unlimited amount of procsessing distributed among the clients.
Insert Generic Sig Here:
Why should I make the sever process this.
Javascript has plenty of uses, but relying only on client-side code to validate data is a recipe for disaster.
On the server side, it's usually an extremely simple action to check the validity of the data.
The server MUST have functions to check for data integrity.
You should also enforce the rules in the database.
If you rely on the client to do all this, you'll need to deal with buggy clients, or people who copy your page, create their own cracked version of the page, and use the cracked version to screw with your server.
There's plenty of use for client-side javascript, but you shouldn't use it as an excuse to exclude server-side security.
94% of Repubs and 21% of Dems voted to renew the Patriot Act
I'd love to see IBM bundle their Eclipse IDE with tools that convert IE-only (or Netscape/Mozilla/Firefox-only, for that matter) code to truly cross-browser code. Automated conversion. They've got the manpower and other resources, including global human testers. And the more productive is this "migration" program, the more money IBM makes selling hardware and services to the defragmented market.
--
make install -not war
You guys actually get, like, a real.... document? Like with writing in it, describing in some detail what people actually want?
I thought they were myths.
Where I work, people's minds change, sometimes on a weekly or even daily basis. Sometimes it's a good idea to plan ahead to be able to keep up with those changes.
You can accomplish anything you set your mind to. The impossible just takes a little longer.
For example: You have used a div with stylesheet ID "X" having attribute 'clear: both', and then followed that with another div. This will probably display incorrectly on IE5.x on Macintosh, because it incorrectly uses lexical instead of block scoping for the clear attribute on boxes.
I'd pay money for that. Anyone want a new project?
I don't think M$ is dumb enough to break IE5/6
LOL!
OK, you owe me a new keyboard, as it's now covered with soda.
I'm remembering the problems I've had when I was working with IntraLearn, and the way it broke when going from IE 5.5 to IE 6.0, and how stock 6.0 worked but the latest Service Pack didn't. I ended up decrypting their damn Cold Fusion code and fixing it myself.
IE breaks a lot of things between versions. I've come to the conclusion that the IE developers at Microsoft just can't keep things working form one version to the next. Hell, I've even seen small security patches break sites.
Ever try to open up an HTML file generated by Powerpoint 95 in IE 6.0 SP2? In Windows 2000? It's a disaster, and half the links don't work, and that's using nothing but Microsoft products. Because it looked fine on IE 5.5, and the company owner was running IE 5.5, he concluded that it must be fine, and I was the one who was chewed out when it didn't work for the sales guy who did a demo on W2K running the latest IE.
"Live Free or Die." Don't like it? Then keep out of the USA
For a recent project some initial tests showed that (especially on IE) generating an HTML string (preferrable building the string into an array and getting the result string with array.join('')), was 100-1000 times (!) faster than modifying the DOM tree. Marking the difference between something that works and something that's unusable.
I saw an implementation of a website that ran against an application on an NT which connected to a mainframe which then ran batch COBOL to generate reports, ship them back to the NT server, formatted via PHP and into peoples browsers.
On the internet, no one knows you're a mainframe...
putting the 'B' in LGBTQ+
It's good when people fix problems in their web apps. But, realistically, a lot of companies aren't going to bother; touching large amounts of old code is a dangerous and costly proposition.
I think the solution is a different one. Greasemonkey has already been used for the purpose of fixing IE-only problems, and it's relatively easy to write new scripts that patch up problems in IE-based web apps. I think that's the path towards helping making Firefox an even better replacement for IE.
Of course, Greasemonkey itself isn't mature and has problems. The recently discovered security problems are serious but fixable.
More important is that Greasemonkey scripts may be too much trouble to install right now for deployment. Greasemonkey would be greatly enhanced if it could be set up to access script repositories through http and/or WebDAV. That way, intranet administrators could point their users' Firefox browsers at a secure, internal Greasemonkey script repository and add fixes as they encounter them.
I've spent the past few weeks porting code from Firefox to IE. It's been hell. I need to find the location of user-selected text in the document: Firefox supports (mostly) the W3C Range object, which provides a DOM node and offset, but IE's proprietary implementation provides only the pixel location (!). I tried using a trick with copy & paste to locate it, but when IE provides the content of the selection it tries to be clever: it adds tags. It also adds tags when you paste. So if you copy the selection and paste it right back where it came from, you'll get a broken document!
Both browsers also corrupt whitespace. The Firefox DOM collapses multiple spaces in a text node to a single space (sort-of - they're also still there, which is very puzzling). The IE implementation goes one step further and collapses spaces across element boundaries. So, for example, a leading space following a start or end tag may vanish (or not, depending on whether it preceded by whitespace). It also inserts newlines following tags for block elements. Oh yeah, and it capitalizes tag names and drops some close tags while it's at.
One more appalling bug: the DOM normalize function in IE crashes the browser. But only sometimes.
I've solved my problems, but it has taken longer than it did to get the whole system working in Firefox in the first place. (It's a web annotation system that allows for highlighting and margin comments for arbitrary HTML - I need to find the selection when the user creates a highlight.) The world would be a better place if IE crawled off and died.
Only problem is, if you wait until they ask it's going to take you time (and lots of it) to re-design and recode everything. They're likely motivated by something major, eg. possible legal liability if they continue to allow known security problems, and you're then going to get back from them "Well, we can't wait N months for you to convert. Your competitors already support non-IE browsers, we're going to them.".
I looked so you don't have to:
. is.only.xul
http://www.mozilla.org/keymaster/gatekeeper/there
For those that don't know- you can develop web ASP.net applications that leverage 3 types of authentication- Forms, Windows and Passport. Forms and Passport will work for all browsers. Passport authentication costs a lotta $$$ so you only see it on MS sites and large commerce sites like Expedia. Forms is the simple authentication that every browser will render- it requires you to write custom code to handle authentication. This means your code needs to do work like checking a password file, looking into a database, etc. You'll also need to write code that meets your company's security policies. It adds a lot of time and expense to application development. Windows authentication uses your Active Directory session- none of the custom code in forms authentication is necessary. You just set the acls on the directory of the app, and as long as the user is logged into the domain and their group has access permissions, the domain handles authentication and authorization issues. No worrying about password complexity algorithms, password aging or user account management. You save cash and you ensure that security requirements are applied consistently.
Single sign-on (in this instance, windows authentication asp.net apps) solves a significant number of organizational security problems. Reducing inconsistency in password complexity, password aging, access management, etc, should be a primary goal in business web applications. This is an instance where IE only solutions are better than Netscape, Mozilla & Firefox apps. This article is missing the only reference that is really necessary- how can I offload my security concerns into a single clearinghouse with Firefox/Netscape/Mozilla. If someone does a samba like project to figure out how to kludge in Windows Authentication into the other browsers, then this article will be complete.
I'm sticking with I.E. only solutions for Intranet business applications because it contributes to centralized security.