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."
All in all, bug for bug, line by line, even accounting for the massive differences in complexity (mozilla is by far a more complex project that IE ever wanted to be), I'd have to say that Mozilla has less show-stopping bugs and fewer exploits than IE.
Like what I said? You might like my music
A bug in mozilla??? No way, you've got to be jokeing!!!
Seriously though, although Mozilla has it's faults, (this being a prime example). It is still the cutting edge of browser technology. I mean, theres one feature that wins over every person I've recommended Mozilla to: the ability to stop pop ups from apearing. ALthough Mozilla is still rough around the edges, it is still my browser of choice.
"Entropy is the bad-guy, and he is everywhere"
Finding Bugs like this is proof that Mozilla is well on the way to becoming the world's best browser. With open source and lots of people contributing, bugs are found and elliminated quickly.
Microsoft IE on the other hand, bugs take time to find and even more time to repair due to the slow reaction of a large organization. This is probably why we hear so much about Mozilla bugs, they're far easier to uncover than bugs in IE or other browser.
PErsonally, I think Mozilla users should concider this a Good Thing, it means that your browser of choice is getting better!
"Entropy is the bad-guy, and he is everywhere"
What I'd like to know (and this is NOT meant as a flame any way, I love mozilla), is HOW exactly do big bugs like this get into final releases? I mean, the 1.2 release was more than a month behind what was scheduled on the roadmap, and yet it still ends up with this in it? Is it just the number of people who don't bother with nightlies or reporting bugs? I would think there would be enough people using the nightlies to find fairly significant bugs like this. Perhaps the fine mozilla people need to add a "gamma" release after "alpha" and "beta" but before "final"? Have the gamma and final be seperated by one week, and ONLY incorporate bugfixes which don't affect major parts of the code? I don't quite know what the answer is, but it seems something should be done. All in all though, great browser.
it's rather the way these bugs are treated and fixed. With a MS product, some bugs are not acknowledged until they have a fix, sometime months after the first discovery.
with an open source model, bugs are public and are generally much quicker to be patched.
The best cure for insomnia is realizing that it is already time to get up. EsteEncanto.com - Blog on technology, urban
No, if this were an IE bug, sites would have been designed around it in the first place and no one would ever notice except for the web designers.
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
That's actually not entirely true.
One of the websites I helped build is broken in 1.2 (just noticed it yesterday). This was working fine in 1.2b, as well as in a homebuilt CVS version somewhere in the cycle leading up to 1.2.
I think a "Release Candidate" should have been put out, which when tested for a while should have become 1.2 final without any further changes.
As Mozilla issues go, this has got to be one of the more annoying ones, but apparently nobody wants to actively work on it. "Composer" is actually not a bad WYSIWYG html editor at all - it has alot of potential. But as long as it strips / corrupts PHP and other scripting code, it will never be very useful to anyone doing anything beyond the most trivial of web pages.
The Mozilla-dev folks need to wake up and realize that just about any web designer these days is using some degree of scripting.. Composer needs to at the very least ignore (and not corrupt) scripting blocks. Composer is quite an excellent html editor generally, but as long as it continues to act brain-damaged in regards to any unknown blocks it encounters, it is not going to be truly useful for anybody other than your Great Aunt Emma working on her Geocities homepage.
Right now, if you need PHP and still want to do your page design in Composer, you have only two options: (1) Every time you tweak the page in Composer, insert all your PHP by hand, or (2) Put your own "#PHPBlock1" tags in the html and have a script replace it with the neccessary PHP code later. Having to do either is annoying. Composer simply shouldn't mangle PHP blocks at all.
I'm pretty sure there's another outstanding bug regarding the fact that Composer cannot save 'fragments' - if you're merely designing a table or template to be generated via PHP, there is no way to have Mozilla save it as a fragment, without header tags etc. A bit of a nitpick, but really, how much effort would it take to code in a "Save as fragment" option?
Mozilla is quite an impressive accomplishment for open source, I really do think Mozilla smokes IE hands down these days.. but these Composer bugs should have been fixed long ago - not enough people care about this aspect of Mozilla. A little bit of work here could go a long ways towards undercutting commercial HTML editors in a big way.
Is it not enough reason that this is a bug? We should stop release for all bugs! But seriously....
A big reason is that DHTML is pretty much just a way of saying the W3C DOM and a few DOM Level 0 (no spec) APIs. This bug effectively cripples our standards support and I would definitely call that serious.
On top of that, with every release, there is a chance that some embeddor will want to base their product off of it. Embeddors generally like DHTML, and this would be a show stopper for them.
"The Mozilla team had been alerted to major bugs which only recently appeared in the browser"
Sorry. Just because you filed a bug and posted a comment on another does not mean the Mozilla team was alerted. If there is a showstopper bug, filing it in Bugzilla does not guarantee it will get noticed if everyone is busy with final preparations for a release, and trying to get ready for the impending alpha. Don't forget that the people involved with Mozilla get tons of email from bugs, review requests, etc. as well as have real lives in which they eat turkey and go Christmas shopping. Bugs sometimes slip through the cracks. Hop on to IRC next time and make sure that one of the drivers, or even a developer or QA person knows about your bug if you think it is an absolute showstopper.
It definitely sucks that this bug was in a release. But things happen. Hopefully it won't again.
Caveat: I use Mozilla as my primary browser. That said, I'd like to make this observation:
It seems to me that we spend a lot of time on Slashdot talking about Mozilla as a premiere project of the open source community. However, my impression is that Mozilla is largely still an internal project of Netscape (and by extension of AOL Time Warner). This impression is based on, among other things, the very large number of @netscape.com email addresses that pervade Bugzilla, the mozilla.org web site, etc. I can't believe that Netscape's engineers restrict themselves to working solely on their release branch of the Mozilla codebase during working hours.
I don't think it at all diminishes the magnitude of the Mozilla project's achievement to say that it has made progress largely under the aegis of AOL/TW. But we should at least be honest that Mozilla is furthering the agenda of a very large corporation that is just as rapacious and profit-motivated as Microsoft.
Anyone have any hard data about the investment that AOL has made in Mozilla development?
but we don't go party, if there is a bug announced and say "ha ha, you aren't any better than we".
/.ers celebrate like a bunch of immature teenagers, fogetting that OSS is not going to succeed because how bad the competition is, but because how good a given OSS is.
Hello? For years when IE was still in its infancy, every bug was celebrated and shown as "proof of incompetency" on Microsoft's part.
Even now every time a severe bug is found in Microsoft
The DHTML bug was caused by an 1-character-incorrect backout of a patch that I did in too much of a hurry (removed the entry from the list, but didn't adjust the count). Mea Culpa. This happened 2 weeks before 1.2 final, but most testers were working on 1.3 by that time, and the ones that weren't didn't visit the type of DHTML that causes the problem (most DHTML doesn't have the problem). There was a separate problem where the wrong files were tagged (some recent fixes weren't included).
We're fixing these and will have an updated build up soon. How long would Microsoft take to fix this sort of problem?... (Let alone tell you why the problem happened.)