Migrating IE Web Apps to Mozilla 407
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."
Read my last journal entry... (Score:2, Interesting)
Firefox tools (Score:5, Interesting)
And why would most use IE anyway? (Score:5, Interesting)
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
Article not just IE to Mozilla but also Opera (Score:2, Interesting)
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.
Not priter friendly (Score:3, Interesting)
Re:How about making server side only apps? (Score:2, Interesting)
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.
Re:How about making server side only apps? (Score:5, Interesting)
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.
Automigration (Score:3, Interesting)
Advocate of terse programming? (Score:1, Interesting)
var foo = (condition) ? conditionIsTrue : conditionIsFalse;
Since when should terse programming be advocated like this? Give me a break. I thought programmers were aware of the fact that terse statements only serve to complicate code readability and should not be used. There are acceptable uses of terse syntax (the ++ increment operator, for example), but the ternary operator has never been one of them.
Just a second... (Score:3, Interesting)
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.
What I'd really like... (Score:3, Interesting)
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?
Re:Here's the deal... (Score:3, Interesting)
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.
Re:innerHTML, the big enemy (Score:3, Interesting)
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.
Re:Read my last journal entry... (Score:1, Interesting)
Two comments from a long-time QA/VV&T and process improvement analyst;
1. You are talking about requirement details vs. implementation details.
In this case, the requirement is that the job be done properly. The implementation is how the job will be performed.
Score 1 point for you: You did the job as required and did it effeciently. The tools you chose should not matter to your boss and they should be thankful.
2. Severity levels are ranked from cosmetic/low up to critical/showstopper.
Part of the definition of a critical/showstopper is that either the tasks can not be performed or there is data loss/corruption.
Score 1 point for your boss who thinks E is the name of the web site; there was data loss.
The result: Your manager seems to be taking the right actions; they noticed a critical event (data loss) and stopped the source (Firefox). That you have been given the right to continue to use Firefox + scripts shows that your boss isn't a total moron.
It is not an elegent solution, nor does it do things in the most effective manner. Till they spend time looking over how efficent the current process is and what can be done to improve it, they are doing the correct thing; stop known data loss. (Yes, they should be stopping OTHER DATA LOSS too, though that is a seperate problem at this point.)
Ideally, your boss' boss should be paying attention to how call times are so out of whack and ask your boss "Hey, why does NoMoreNicksLeft do so well being a 6 month old employee, and JaneLongTimeEmployee handles only a few calls above the average?"
Your boss' boss shoud be hammering your boss for an answer...or even better, they should march down and talk to you for 10 minutes and ask basic questions; no dictating, just watching and listening.
These simple steps are almost never done. Anywhere. So, you end up with the absurd situation you have here.
Bottom line: Firefox + your scripts should be investigated. A standard configuration should be tested. If it is OK, the standard config should be deployed everywhere. The standard should be used in training, starting with a few people and expanding out from there. A minimum of 2 weeks of field testing should be performed on a small group. More time should be spend if no immediate improvements are found. If dramatic improvements are noticed within the first 2 weeks, more people should be added to the test till it is certian that no additional critical problems are encountered and efficency goes up.
Re:How about making server side only apps? (Score:3, Interesting)
On the internet, no one knows you're a mainframe...
maybe we should fix it ourselves (Score:3, Interesting)
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.
Text Range and Whitespace Differences (Score:2, Interesting)
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 [geof.net] 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.
Re:The forgot something... (Score:3, Interesting)
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.".
Re:Or you can use XUL (Score:4, Interesting)
http://www.mozilla.org/keymaster/gatekeeper/there
It's missing Active Directory Integration... :^/ (Score:2, Interesting)
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.
Re:Developers. (Score:1, Interesting)
Yes, I have. Way to make ridiculous assumptions based on a short post though. This is completely besides the point anyways since the project this thread is talking about requires the pages to work only with IE therefore your points are pretty much void. Obviously, if the project requires support for more platforms you have to support them as well, however if the project strictly states that it only requires support for IE and you have a short time period making it compatible with other browsers is not going to be a priority and most likely is just a waste of precious development time.
The parent poster is not saying standards are bad he's just saying that if you have a very short time period and the project specifically states that only IE support is needed then you would be wasting time to be testing and optimizing the page for other browsers. This time could be better spent doing other things and maybe even other projects.
"What are you going to do if they give you a requirement to do it in that short, one week period to have it run on IE, Mozilla, Netscape, and Firefox? Hmm? You're going to sit there and not be able to deliver, because you have people who work for you who can't think outside of the box, since all you ever did in the past was design one-sided applications."
You act like this is the only application that these developers will ever make. The point is that for this application the company WANTS IT TO WORK ONLY WITH IE therefore you give them what they've asked for. Perhaps they don't want other browsers to be accessing the site for reasons you're not aware of. I've worked for companies that go even further than that by saying they don't want it to work for anything but specific versions of IE. You don't even address the fact that in a closed environment such as a companies internal Intranet that ActiveX can be used to drastically cut down development time. Have fun wasting coding time working out data binding to Excel sheets through JavaScript when the alternative is to write three lines of ActiveX code and be done with it....