Slashdot Mirror


DHTML Bug Found in Mozilla 1.2

joyoflinux writes "The people at Mozilla have announced that Mozilla 1.2 contained a bug that caused sites that use DHTML to fail (more on the front page). They have pulled 1.2 from the releases page, pending a 1.2.1 release."

8 of 351 comments (clear)

  1. Re:lalaa by IamNotWitchboy · · Score: 5, Informative

    from the mozilla FAQ: "Mozilla 1.0 is a fully functional technology demo for those interested in seeing what can be done with Mozilla technology, and those who want to create Mozilla-based products and packages. The intended target audience is the development community. " so, it's not really a product. but a great 'demo' imho. if you want to use the 'commercial' suite, use netscape.

    --
    The best cure for insomnia is realizing that it is already time to get up. EsteEncanto.com - Blog on technology, urban
  2. bugzilla link by J.+Random+Software · · Score: 5, Informative
    I'm guessing it's bug 182500 (or at least the bugs referred to there). Something about document.write() dropping leading characters.

    IMHO documents that completely rely on ECMAScript are inherently broken anyway.

  3. arrrrggghhhh by vsync64 · · Score: 5, Informative
    This really isn't fair. From the end of my most recent log entry:

    I'm extremely upset. 8 hours ago I downloaded Mozilla 1.2b for Win32 for Joie's parents' computer. It looks like they released 1.2 while I was downloading 1.2b. This isn't the first time a fresh download of mine has been obsoleted, but never this quickly.

    So today I downloaded 1.2. This is quite upsetting.

    Anyway, in order to save Bugzilla the crush, I'm pasting the bug report (#182500) here. It seems that the main issues are broken user-defined XML tags, broken document.write(), and checkins to the 1.2 branch missing in the release.

    This is a meta-bug whose dependencies will be problems caused by the incorrect backout described in bug 167493 comment 21. Some of these bugs have been reported as Windows-only, but I've also been able to reproduce them on a gcc 3.2.1 Linux build with -O2.

    ------- Additional Comment #1 From David Baron 2002-11-28 07:38 -------
    I've corrected the backout on the 1.2 branch (although I admit I only tested the change on the trunk, but I did the backout by backing out the backout with cvs up -j -j and then backing out the original checkin the same way). It remains to be seen what (if anything) we'll do with the 1.2 release.

    ------- Additional Comment #2 From Malcolm Rowe 2002-11-28 08:26 -------
    We may have to do something with the 1.2 branch anyway. Some of the checkins to the 1.2 branch disappeared from the 1.2 release - see bug 182506.

    ------- Additional Comment #3 From David Baron 2002-11-28 09:07 -------
    I think I've gone through all the Browser bugs filed between the 1.2 release and now (mostly by just skimming bug summaries), and added all the relevant dependencies. However, bug 182317 and bug 182433 are probably also dependencies of this bug, but I didn't add them since I'm not sure.

    ------- Additional Comment #4 From Phil Schwartau 2002-11-28 13:21 -------
    Note I've added this bug as a dependency:

    bug 182253, "document.write() eats initial characters in 1.2"

    It explains why so many sites with DHTML menus are being hit by the current bug. The sites are using document.write() to create them -

    ------- Additional Comment #5 From Dawn Endico 2002-11-29 16:50 -------
    I removed links to 1.2 from the releases page and the home page, and announced the release of 1.2.1 when we have a correct tag and new builds. Since this happened on a 4 day holiday weekend the new release may not happen till Monday.

    ------- Additional Comment #6 From Bryan 2002-11-29 17:28 -------
    Hi,
    Yes I did see it happen in that relase but somebody beated me to the punch. Are you giong to remove it form the ftp://ftp.mozilla.org/pub/mozilla/realses page or you going to keep it there for people to download and test this problem. IF you can e-mail me wiht that info that will be great I will like to see still on there for the people who want to take risks like me.

    ------- Additional Comment #7 From Asa Dotzler 2002-11-29 20:10 -------
    We're not talking about a security exploit or even major dataloss here. I see no need to re-write history. The 1.2 release will stay where it is.

    This bug is likely to see some traffic. I'm taking this oportunity to ask all of you folks that read about this bug at mozillazine or slashdot or wherever to not comment. Unless you're actually working on this problem your comments will only get in the way. Thanks.

    [Emphasis mine.]
    --
    TO BUY A NEW CAR WOULD MAKE YOU SEXUALLY ATTRACTIVE.
  4. Re:Interesting by whereiswaldo · · Score: 5, Informative

    No need. Every piece of software known to man has at least one security flaw. The differenced I see are the frequency of flaws found and timeliness of updates. Microsoft loses there. Ask the analysts if you don't believe me. (eg.)

    But I'll just let you read this article.

    Open your eyes, man.

  5. Re:Talk about spin and hyposcrisy. by nagora · · Score: 5, Informative
    It would be better for us, I think, if we just handled the bugs better than MS

    Pulling the release is handling the bugs better than MS!

    TWW

    --
    "Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
  6. Re:but HOW? by caillon · · Score: 5, Informative
    No. The patch was a 1 liner. patch -R would have either reverted it completely or not at all. I would imagine that the file in question was hand edited. The eHTMLTag_userdefined portion was removed but the 9 was not changed back to an 8.

    FWIW, the patch was:

    RCS file: /cvsroot/mozilla/htmlparser/src/nsElementTable.cpp ,v
    retrieving revision 3.140
    diff -r3.140 nsElementTable.cpp
    102c102
    < TagList gHeadKids={8,{eHTMLTag_base,eHTMLTag_bgsound,eHTML Tag_link,eHTMLTag_meta,eHTMLTag_script,eHTMLTag_st yle,eHTMLTag_title,eHTMLTag_noembed}};
    ---
    > TagList gHeadKids={9,{eHTMLTag_base,eHTMLTag_bgsound,eHTML Tag_link,eHTMLTag_meta,eHTMLTag_script,eHTMLTag_st yle,eHTMLTag_title,eHTMLTag_noembed,eHTMLTag_userd efined}};
  7. Re:Interesting by asa · · Score: 5, Informative

    " Interesting that every couple of months when Mozilla has a bug or exploit or something"

    This isn't an exploit or even a crash or dataloss bug. This is just a visual glitch that you'll get on some pages with DHTML. The release hasn't really been pulled and is still available at ftp but we'd rather spare our users a large download that would probably be repeated in a couple of days when the 1.2.1 release out so the high-visibility links were commented out for the time being.

    --Asa

  8. Re:Interesting by asa · · Score: 5, Informative

    Don't even think about commercializing Mozilla when it can't open certain DHTML sites. I've tried 1.2.1 (just now) on both Windows and my Debian.

    Actually, if you're thinking about commercializing Mozilla then our milestone model is probably just the thing you're looking for.

    We push nightly builds to thousands of testers every day, hundreds of thousands of users test and thousands of users report problems against Alpha and Beta Milesotne releases and then we ship a final milestone to even more users/testers.

    In some cases a new problem is discovered in that Final Milestone a fix is landed on the milestone branch. Someone interested in commercializing Mozilla has a well tested and well patched code branch from which to build a commercial product.

    That this bug was discovered in Mozilla is precisely the reason that organizations would want to use Mozilla technologies in commercial products. We keep making it better and when we move on to the next release cycle any commercial (or non-commercial) organization is free to pull the code, listen to Mozilla Milestone feedback and bug reports and continue making it better themselves.

    The alternative is doing all this development and testing work yourself or relying on closed source code where you can't continue making it better yourselves if you do find something wrong. If I was building a commercial app that required HTML rendering then I'd definitely investigate using one of the Mozilla code branches for my products.

    --Asa