Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Internet Explorer Mozilla The Internet

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."
This discussion has been archived. No new comments can be posted.

Migrating IE Web Apps to Mozilla

Comments Filter:
  • Developers. (Score:1, Insightful)

    by Jeet81 ( 613099 ) on Wednesday July 27, 2005 @01:45PM (#13177811)
    I wouldn't call them developers if they develop a web app just for IE. True developers test for compatibility.
  • That's Easy! (Score:5, Insightful)

    by AKAImBatman ( 238306 ) * <akaimbatman@gmaYEATSil.com minus poet> on Wednesday July 27, 2005 @01:47PM (#13177838) Homepage Journal
    Porting IE-only apps to Mozilla/FireFox is easy thanks to the extensive set of DOM and JavaScript debugging tools. It's going the other way that's the hard part. IE is completely unhelpful in diagnosing issues with document.addEventListener (a standard that IE doesn't support), or passing an event instead of using the stupid document.event, or showing you the DOM to find out where (or why) that specific DIV isn't showing up right.

    Meh. Somebody needs to either fix IE, or take it out back and shoot it.
  • ObDuh strategy 101 (Score:2, Insightful)

    by Travoltus ( 110240 ) on Wednesday July 27, 2005 @01:47PM (#13177850) Journal
    It's wise to free your web based product from proprietary stuff like MSIE. That way if MicroSoft turns on you, so what? Life carries on.
  • by pickyouupatnine ( 901260 ) on Wednesday July 27, 2005 @01:49PM (#13177872) Homepage
    The title of the article should say "Migrate apps from Internet Explorer to Mozilla ... with valid business reasons". ... Might be easy to do so with small apps.. but with the size of the apps we've written for intranet based sites... there's no reason to make the switch to Mozilla. We simply tell our clients (who are all windows users anyway) to use IE. Not giving further choice means less headache for us when it comes to supporting our product.
  • Re:Developers. (Score:5, Insightful)

    by Ingolfke ( 515826 ) on Wednesday July 27, 2005 @01:50PM (#13177879) Journal
    True developers test for compatibility.

    Not if the requirements document says build this app for IE only and don't worry about interoperability.
  • by Anonymous Coward on Wednesday July 27, 2005 @01:50PM (#13177882)
    No, no matter how much I love RoR, this is just fanboyism. RoR is server-side, XHTML, css and cross-browser compatible javascript is the answer.
  • by Iriel ( 810009 ) on Wednesday July 27, 2005 @01:50PM (#13177883) Homepage
    I agree, but a large reason that some developers didn't use server-side code was that it was claimed (rightly so or not) that it took longer to get a result. Now, on the other hand, we can use technologies that like AJAX to speed up the process of getting certain pieces of data back. Now, it's a matter of people putting it all together.
  • by Ossifer ( 703813 ) on Wednesday July 27, 2005 @01:51PM (#13177898)
    Having server processes deliver content does nothing to eliminate browser compatibility issues.

    These issues lie with the developer at heart, and the QA engineers. One needs to ensure compatibility at the unit-testing stage, having followed standards (as in the IBM article) in the design and coding stages...
  • Re:Developers. (Score:1, Insightful)

    by Anonymous Coward on Wednesday July 27, 2005 @01:52PM (#13177913)
    Not every app is open to the world, sometimes the broswer type will be a requirement. It has nothing to do with being a developer (what you want to say is architect, r whatever).
  • by Anonymous Coward on Wednesday July 27, 2005 @01:53PM (#13177929)
    Being IE-specific is the mark of lack of foreseight. I speak from experience, unfortunately. To be cross-browser compatable between the latest versions of IE and mozilla is exceptionally simple if a little care is taken upfront. Unfortunately massive, hand-written, IE-specific sites are likely not worth the cost to rewrite. Consider your lesson learned and do it right NEXT time, forget porting.
  • Re:Developers. (Score:3, Insightful)

    by Iriel ( 810009 ) on Wednesday July 27, 2005 @01:56PM (#13177972) Homepage
    It all depends on the target audience. If the company is making Windows only software, then they never had to test something on Safari or IE 5.2(mac). Some companies, also, don't see a point in catering to those that aren't in the majority. If the loss of one or two users that use non-IE browsers is negligible at the time, then why waste the money on cross-platform testing? Too many businesses run thier web sites like a democracy: 3 wolves and 1 sheep voting on what to have for lunch. Mob wins.

    On the other hand, if IE starts falling out of power, then some companies may regret those poor choices, and some already are.
  • Here's the deal... (Score:1, Insightful)

    by Saeed al-Sahaf ( 665390 ) on Wednesday July 27, 2005 @02:05PM (#13178072) Homepage
    I'm sure, with your small World View and asinine opinion, you are not in any position to "do business" with them anyway. Generally, code monkeys like you are LOW on the totem poll.
  • by tscheez ( 71929 ) on Wednesday July 27, 2005 @02:06PM (#13178080)
    and get iNotes to work better in firefox
  • Already been done (Score:2, Insightful)

    by goldspider ( 445116 ) on Wednesday July 27, 2005 @02:08PM (#13178105) Homepage
    "Get Mozilla/Netscape, Opera, Microsoft, etc all in one room and decide on a standard."

    It's called the W3C [w3c.org].

    Sadly, despite the W3C's efforts, it seems that the Browser Pissing Contest rages on.

  • by Anonymous Coward on Wednesday July 27, 2005 @02:11PM (#13178148)
    Don't forget the cardinal rule of data validation: "Use javascript to make things work well for the user and server side validation to prevent hacks."
  • by Penguin Programmer ( 241752 ) on Wednesday July 27, 2005 @02:18PM (#13178216) Homepage
    Unfortunately for us all, this attitude is very common. My approach is quite the opposite: code to the standards so it works/looks correct in FF (or other mostly-standards-compliant browsers), give it basic functionality in IE and if an IE user complains about it not being perfect tell them to use a proper browser.

    Obviously, when doing work for the company I have to be careful and make things look at least reasonably proper in IE (for which the IE7 javascript library has been a lifesaver). However, for my local LUG's webpage, I can just tell IE users to switch browsers or go fuck themselves.
  • You guess wrong (Score:4, Insightful)

    by jag111 ( 55724 ) <slashdot.com@nosPaM.xyto.cc> on Wednesday July 27, 2005 @02:18PM (#13178226)
    I pity the pour souls who were forced to use your "huge and widely used" web app that was compatible only with IE. It's clear you didn't do your homework before starting the project. ASP.NET web apps do not require having the .NET runtime on the client any more than PHP web apps require installing PHP on the client. (read: they don't)

    All of the native framework web controls have two distinct rendering modes. One is for "uplevel" browsers which includes any javascript/DHTML/etc. goodness that the latest browsers support. The other is for "downlevel" browsers and basically renders everything in something like HTML 3.2 compatibility. The server runtime detects which mode to use based on a section of the machine.config called browserCaps (essentially the .NET equivalent of browscap.ini). The default values stored in the machine.config basically only recognize 5.x+ versions of IE as "uplevel" browsers.

    Updated versions of the browserCaps info can be found here:
    http://www.codeproject.com/aspnet/browsercaps.asp [codeproject.com]
    It should be noted you can choose to either replace the data in your machine.config to make it a system-wide update, or just add the same data to your app's web.config file.

    On a related note, you can find an updated version of the original browscap.ini here:
    http://www.garykeith.com/browsers/downloads.asp [garykeith.com]
  • by DaHat ( 247651 ) on Wednesday July 27, 2005 @02:28PM (#13178313)
    On it's way out? Do tell, where are you getting this from as in my experience .NET is one of the greatest things since sliced bread when it comes to coding windows or web based applications.
  • Re:Developers. (Score:2, Insightful)

    by Anonymous Coward on Wednesday July 27, 2005 @02:29PM (#13178332)
    A good developer will recognise that the requirements doc is tremendously short-sighted, and code for compatability anyway. He'll save the customer a surprising amount of money when they inevitably decide to support Firefox after all, though no-one will realise this.
  • by rainman_bc ( 735332 ) on Wednesday July 27, 2005 @02:38PM (#13178428)
    And that's how shit like Code Red and Nimbda spreads. The "Leave it alone" attitude is generally bad - and a good IT person should spend their time preventing that crap.

    Problem is that patching servers is boring, and they have more interesting things to do like deploy something new and noteworthy.
  • by Leebert ( 1694 ) on Wednesday July 27, 2005 @02:42PM (#13178475)
    We simply tell our clients (who are all windows users anyway) to use IE. Not giving further choice means less headache for us when it comes to supporting our product.

    That's a perfectly acceptable position to take. As long as your competitors take the same position, that is.
  • by hexed_2050 ( 841538 ) on Wednesday July 27, 2005 @02:42PM (#13178482)
    Websites that require IE only are very unprofessional IMHO.

    If I have to use IE to use a website, my opinion about the company's website I'm on is usually changed. In this day in age, you have to be proactive, not reactive.
  • by Anonymous Coward on Wednesday July 27, 2005 @02:43PM (#13178499)
    For small orgs, there are lots of next time things, and not much time for them right now. Firefox support is a perennial 'next time' list for me because it's never been requested by a client. However, once it is requested and paid for once, I'll learn how to do it, and I'll do it every time.

    It's lack of resources, not lack of foresight.
  • Not it doesn't (Score:3, Insightful)

    by samjam ( 256347 ) on Wednesday July 27, 2005 @02:44PM (#13178519) Homepage Journal
    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.

    And an unlimited amount of dodgyness. It doesn't make the application more robust at all but it might give a better user experience.

    Any validation the client does MUST also be performed at the server end because
    (1) How do you know the client DID validate it
    (2) correctly
    for some ill specified and overly cached version of "correctness"

    Sam
  • by HiThere ( 15173 ) * <charleshixsn@@@earthlink...net> on Wednesday July 27, 2005 @02:50PM (#13178568)
    Actually, his position is not unreasonable, although he did state it in an undiplomatic fashion. I, personally, do not and will not connect to the internet (or even the local net) with MSIE installed on my computer. I consider it excessively dangerous. So if I cannot test or use the proposed application, I would not be willing to do business with them. If I had to go to a special computer that was specifically isolated from the rest of our network for security reasons to use their applications... well, it had better be an important application that I won't need to use very often.

    I have not yet been able to ensure that the others that I work with do not have MSIE installed, but that is one of my goals. In furtherance of this goal, I will not suggest any application vendor that I know provides MSIE only applications. And I will not recommend any MSIE application. And I will recommend against the purchase of or use of any such application. (This doesn't mean that I'll always come right out and say why I'm against the application. Those who know me well will know my attitude towards MSIE, and they will need little explanation. For others, I'll find some easier to understand reason that is also correct..or I'll be silent...but security issues are almost always present, if I can't find any other valid reasons. A better approach, when there is time, is to come up with a competing product that I find superior.)

    I consider MSIE to be a security nightmare, and we will have as little to do with it as I can manage.
  • Re:Developers. (Score:1, Insightful)

    by Anonymous Coward on Wednesday July 27, 2005 @02:53PM (#13178598)
    A good developer will recognise that the requirements doc is tremendously short-sighted, and code for compatability anyway.

    If I did that, I would be fired.

    I am dead serious.

    My employer is adamant about making use of specific IE-Only features, and about 'wasting' zero development effort on cross-browser compatibility. I do think this is short-sighted (and have said as much), but the fact remains that the person who signs my paychecks has given me very clear instructions on how I am to spend the development time he has purchased from me.

    This does not make me a bad developer.

    Oh, and I humbly suggest that you use a spell checker next time.
  • Use Standards (Score:2, Insightful)

    by aaronfaby ( 741318 ) on Wednesday July 27, 2005 @02:57PM (#13178634)

    It's not hard to code cross platform. Developers are just lazy. If web developers stuck to W3C standards than this wouldn't even be an issue. If game developers used OpenGL instead of DirectX than it would trivial to port games between platforms. And so forth.

  • Re:Developers. (Score:3, Insightful)

    by KiltedKnight ( 171132 ) on Wednesday July 27, 2005 @02:58PM (#13178658) Homepage Journal
    This is why there are W3C standards. If you build to the W3C standards, the browser the client uses should be immaterial.

    The problem arises when you depend on proprietary extensions.

    Also, based on your argument, what do you consider an acceptable loss from potential sales revenue? Do you consider excluding 10% of the market to be acceptable? What if that 10% had a large chunk of disposable income and would be more likely to buy your product? Just because the "majority" uses IE doesn't mean it's right to exclude the minority who choose not to or cannot.

    If anyone's being moronic, it's you.

  • by Anonymous Coward on Wednesday July 27, 2005 @03:06PM (#13178736)
    You can not write Server-Side applications for Load-Balanced servers, becase you can not guarantee that a subsequent request may not be resent to the same server. Especially in round-robin load balancing scenarios.

    Tom
  • by mla_anderson ( 578539 ) on Wednesday July 27, 2005 @03:08PM (#13178752) Homepage

    Javascript has plenty of uses, but relying only on client-side code to validate data is a recipe for disaster.

    Yes and no. If that is your only method for validating data, yes it is a recipe for disaster. However it can be very handy to validate data before a form is posted to make it easier to alert the user. Of course the server side componants should also validate what they receive as you state. A good three tier design needs to check validity on all three tiers.

    I use a lot of javascript to make the UI cleaner (usually simple scripts), to make small changes to objects without having to reload a large page, and to validate form data before it is submitted. Since this is a company internal site I have the advantage of a limited number of browsers, nearly 50/50 between IE and Mozilla. Under these circumstances I can make use of javascript to a much greater extent than if I were creating a public face.

  • Money talks. (Score:3, Insightful)

    by Mr. Underbridge ( 666784 ) on Wednesday July 27, 2005 @03:15PM (#13178810)
    I'm sure, with your small World View and asinine opinion, you are not in any position to "do business" with them anyway. Generally, code monkeys like you are LOW on the totem poll.

    Not when we have $$$ to spend. I do, and if your site won't let my browser through, you lost a customer.

    It's also a good harbinger of how good their customer support is in general, I've found.

    I would also point out that the ones with the small "world view" are the ones supporting only one browser.

  • by donscarletti ( 569232 ) on Wednesday July 27, 2005 @03:23PM (#13178886)
    No, now your just sounding silly, trying to justify what you just said with some incoherent handwaving. What you did is simply just describe W3c a second time while denying that it is actually like that. W3c has coders from all major browsers in the HTML comittee. What they do is sit around and make compromises and agreements for future versions of Html, that is the only way w3c makes standards, that is what they are: an industry and academic consortium where the interested parties can decide what should happen next. It's the developers working out what they can and should support and trying to get it all as similar as possible.

    The problem is that Microsoft just dosen't seem to give a damn what the W3c has to say about anything. Microsoft is a huge part of the standard making process but is not willing to abide by the rules it helped create. Any more discussion outside of w3c would be pointless because Microsoft would ignore that too.

    The reason POP, telnet and FTP are standardised is that they were fully locked in concrete, with nobody willing to debate them further by the time Microsoft got onto the scene, thus they had no chance to embrace and extend them. The very fact that no more debate was allowed (unlike with w3c and HTML) is what saved them from a similar fate.

    Next time you have a great idea that seems so obvious that it is brilliant, maybe you should simply look into what the w3c actually is when it is mentioned before you start prattling on about its shortcomings as a standard setting body.

  • by Phroggy ( 441 ) * <slashdot3@ p h roggy.com> on Wednesday July 27, 2005 @03:29PM (#13178948) Homepage
    Standards-compliant code works on all modern browsers,

    Bwahahaha!

    You obviously don't do professional web design. Getting the code to validate at W3C is the easy part!
  • Re:Use Standards (Score:3, Insightful)

    by 6Yankee ( 597075 ) on Wednesday July 27, 2005 @03:30PM (#13178970)

    If web developers stuck to W3C standards than this wouldn't even be an issue.

    And browser developers. If browser developers stuck to W3C standards, web developers wouldn't even have a choice.

  • Insightul??? (Score:3, Insightful)

    by Nik13 ( 837926 ) on Wednesday July 27, 2005 @03:33PM (#13179001) Homepage
    This is a blantantly uninformted opinion. .NET is anything BUT going away. Heck, the new .Net framework 2.0 is out November 7th, VS.Net 2005 (and it's "express" counterparts), VWD 2005, SQL Server 2005 in the same time frame (some the same day).

    This brings us ASP.Net 2.0, which is so much of an improvement over the old ASP.Net, it's just amazing. Honestly I didn't care much for ASP.Net until I tried v2.0. It amazed me FAR more than everything else I've seen (like RoR, Zope, Plone, etc). Its good enough that I don't even wanna use anything else anymore (asp/php/whatever? no thanks!)

    It's anything but deprecated/on it's way out or being replaced by something better (much the inverse - other platforms are adopting it - ever heard of Mono? I guess not.). It's currently THE best platform to develop for (web wise) and that has the best tools (VS.Net 2005 rocks).

    See for yourself [asp.net]!

    Clearly, you have no idea at all about all this. No wonder you posted as AC.
  • by drico ( 868019 ) on Wednesday July 27, 2005 @03:54PM (#13179217) Homepage
    IE compared to Firefox plus some web development specific extensions (webdevelopper, html debugger, javascript debugger ) is like notepad vs Vim. And my experience is that web application developped with firefox generally works very well in IE, but not the contrary.
  • Re:That's Easy! (Score:1, Insightful)

    by Anonymous Coward on Wednesday July 27, 2005 @03:55PM (#13179220)
    Use visual studio - it has a WONDERFUL debugger for javascript and integrates well with IE.

    I like it even better than the FF debugging tools and miss it sorely when working on Linux or bsd.
  • by Cyn ( 50070 ) <(cyn) (at) (cyn.org)> on Wednesday July 27, 2005 @04:02PM (#13179307) Homepage
    Don't rely on it, and don't dare trust it. Think of it as a service to your users. Oh, and add it on last, once the rest of the system works.

    Client-side validation of a big long ugly form that the user has to submit along with, say, a few MBs of files - is a way of saying "We don't hate you, and don't want you to hate us".

    Don't dare trust it though. Don't trust a damned thing - make no assumptions about the correctness of anything the client sends.
  • Re:Mistakes (Score:2, Insightful)

    by Anonymous Coward on Wednesday July 27, 2005 @04:07PM (#13179362)
    "As far as using onload is concerned, you need to keep in mind that it only fires once all the parts of a page have been loaded - so, for example, if you have ads and the ad server is a bit slow, your onload element might fire thirty seconds after you think it should. This is a big deal when you are manipulating the page content - imagine typing something into an input control, only to have the onload set the focus to the control - in many browsers this will automatically select the text, which means you'll be typing away and suddenly the second half of what you are typing overwrites the first half."

    For a good example of this, try logging into Yahoo! mail on a slow internet connection.

    Username: usernameLastHalfOfPassword
    Password: FirstHalfOfPassword
  • Re:Developers. (Score:3, Insightful)

    by gcauthon ( 714964 ) * on Wednesday July 27, 2005 @04:17PM (#13179473)

    Let's say you are implementing a feature and are faced with two approaches, the IE-only approach and the standards-compliant approach.

    Even if you know your audience is IE users with no choice in browsers, it would still be unwise to choose the IE-only approach. You may be relying on some undocumented side-effect of IE that will get "fixed" in their next release/patch.

    As an example, I had to support an app that provided a list of items as anchor tags. IE did not require the anchor tag to be closed since it would automatically close it on the next "</p>" tag. After upgrading to IE 5.5, this "feature" started causing stack overflow exceptions.

    Most people, when they say "IE-specific" they actually mean "IE version x/windows verion y/service pack level z"-dependent.

  • by NoMoreNicksLeft ( 516230 ) <john.oylerNO@SPAMcomcast.net> on Wednesday July 27, 2005 @04:37PM (#13179721) Journal
    I quit that job, AC. But just out of curiosity, what would you have had me do during downtime, retard-manager?
  • Re:Mistakes (Score:2, Insightful)

    by Myko ( 11551 ) <{myko} {at} {preg.org}> on Wednesday July 27, 2005 @04:39PM (#13179757)
    As far as using onload is concerned, you need to keep in mind that it only fires once all the parts of a page have been loaded ... imagine typing something into an input control, only to have the onload set the focus to the control

    This is exactly why I always fire a function onload that checks to see if the field to get focus has content first. If it does, then I don't focus it.

  • by PhYrE2k2 ( 806396 ) on Wednesday July 27, 2005 @05:32PM (#13180308)
    Yeah- it's a very big 'can`t we all just get along' comment. I'll admit it.

    I guess the comment is just trying to point out that there is no BENEFIT to not keeping to the standard and setting it. If they want to do something other than what W3c says, why not suggest it and let everyone adopt it or provide better solutions- as another pointed out, this is what w3c is for.

    And you think people will listen? HA! Who cares? For the user, IE displays pages fine, so why would a user care about such technical detail of making it right? As long as 10-95% of people are using IE (yes- that means until eternity), people will make their pages compatible for it, so end users will never notice the difference, and never care what some hippie spouting open-source thinks. So no bank or major site is going to let their pages look horrible in IE due to some code changes, so they'll update it.

    And M$ will say that IE is better for A B and C. And then you have a bit war. If there was a right answer, we wouldn't be having this discussion. If there was a superior OS in every way, we wouldn't need two... but each has it's advantages and market.

    -M

Solutions are obvious if one only has the optical power to observe them over the horizon. -- K.A. Arsdall

Working...