If you look at ATI's release notes for their newest drivers, they explicitly list this as an ATI bug.
> why is Mozilla the only application affected by > this bug
Because Mozilla happens to tbe the only app you have that uses the particular functionality that's buggy in the driver, whatever that is? How many apps do you use that do transparency, translucency (fast, mind you), background tiling in hardware, etc?
GCC is s pretty good C compiler. G++ is a terrible C++ compiler (compared to Sun Forte, MSVC++, CodeWarrior, or anything else I've managed to compare it to -- it consistently generates much larger and slower code than those compilers).
People tend to conflate G++ and GCC, unfortunately.
If you look at other large projects of this type (eg Mozilla), both clean builds and dep builds using make are done on automated build systems. The two types of builds will find different types of issues.
A typical bugzilla installation (and this holds for most bug systems) will send one e-mail to everyone cced on a bug for every modification to that bug.
Mozilla's bugzilla gets about 200 bugs filed a day (most of them also get marked duplicate the same day). Each bug generates a minumum of 3 mails -- reporter, assignee, QA contact. That's 1200 mails a day right there (600 to open them, 600 to resolve duplicate).
This is not even including the real work that happens with the bug database... I'd estimate that on a typical day about 10000-20000 email messages are generated by bugzilla.
> This is the first time (that I'm aware of) that a > browser manufacturer intentionally made a browser > that does NOT show what the server is sending to me.
No, the first time was when Microsoft introduced content-type sniffing.
1) AOL Communicator is a pet project of a AOL VP who hates Netscape and wants the division to disappear. It's not clear to me how he thinks Gecko will get maintained after that.
2) Mozilla developers developed XUL because it makes UI development a lot faster and easier than using WxWindows.
The real problem Mozilla is facing right now, imo, is not the UI toolkit but the fact that Gecko is likely to be very much obsolete in 2-3 years unless a good deal of major work happens in the very near future...
The main reason is that MSVC++ produces much smaller (and faster) code than g++ does. This is especially true because g++ 2.9x is being used, with only -O (not -O2, because that produces buggy code) optimization.
Moving to gcc 3.2 (once the Sun people get off their friggin' asses and compile Java with it) will help perf and footprint a lot (15% improvement or so last I heard).
> It's a challenging movie that asks questions > without providing answers.
If it failed to do that it would _really_ be crap, since the whole point of Solaris (the book) is such questions... The point is, the questions it's asking are not nearly as challenging as the ones that it _could_ be asking (and that that book _does_ ask).
Some developers never test their changes, yes. I've seen people check in stuff that they obviously did not compile (it failed to build on _every_ supported Mozilla platform) much less test.
Quite correct. Mozilla.org does not provide end-user support; imo anyone who has issues understanding what the above SSL warning means would have issues using Mozilla in general. (Without support from some entity like their OS distributor, of course.)
Emacs also has a very nice auto-save. The only problem is that revert-buffer needs to be used _very_ rarely, while saving is so common I now hit C-x C-s at intervals without thinking (which _sucks_ in web browsers).
Fundamentally, there is no reason why revert-buffer can't use a temp file somewhere like auto-save does now, with auto-save writing to the main file. That would make a lot more sense, in fact....
IE/Mac and IE/Windows have nothing to do with each other. IE/Mac has typeahead find and has for a long time (and is generally a much better browser than IE/Windows).
The core group is not working on IRC Chat or Composer (except insofar as textareas need to work). IRC Chat was initially done by one person and is now maintained by three people or so.
That's how open source software works. Someone wanted an IRC client? They wrote one. If that's what they want to spend their time on, who's to stop them?
The number of people who know enough about the view manager to fix that clipping bug is about... 2. Of these two, both are full-time students (one's a grad student who spent the summer actually trying to make progress on his thesis). So they just haven't had the time to get into this problem....
Um... this is a _web_browser_. It happens (unfortunately) to come with an HTML editor. Are you using that to edit XML? Because that would be a little odd, no?
Slashdot Mirror
Yes, but it was _REMOVED_ for 1.3. So changing that pref in 1.3 does absolutely nothing.
Clicking again does re-contract.
Hovering the image changes the cursor to a resize cursor, so it's clear that clicking will do _something_.
> Maybe it's a Mozilla bug and not an ATI bug?
If you look at ATI's release notes for their newest drivers, they explicitly list this as an ATI bug.
> why is Mozilla the only application affected by
> this bug
Because Mozilla happens to tbe the only app you have that uses the particular functionality that's buggy in the driver, whatever that is? How many apps do you use that do transparency, translucency (fast, mind you), background tiling in hardware, etc?
GCC is s pretty good C compiler. G++ is a terrible C++ compiler (compared to Sun Forte, MSVC++, CodeWarrior, or anything else I've managed to compare it to -- it consistently generates much larger and slower code than those compilers).
People tend to conflate G++ and GCC, unfortunately.
> They are not going to discover anything of real value to us now.
And that mode of thinking is why history repeats itself.
There is no proof in that store past unsubstantiated claims.
Further, that story does not address the SecurID issue.
The patch was not checked in to the Mozilla trunk because it was vetoed by drivers@mozilla.org. It will likely never be checked in.
How about doing some tiny little bit of fact-checking? Who needs news if it's false?
If you look at other large projects of this type (eg Mozilla), both clean builds and dep builds using make are done on automated build systems. The two types of builds will find different types of issues.
A typical bugzilla installation (and this holds for most bug systems) will send one e-mail to everyone cced on a bug for every modification to that bug.
Mozilla's bugzilla gets about 200 bugs filed a day (most of them also get marked duplicate the same day). Each bug generates a minumum of 3 mails -- reporter, assignee, QA contact. That's 1200 mails a day right there (600 to open them, 600 to resolve duplicate).
This is not even including the real work that happens with the bug database... I'd estimate that on a typical day about 10000-20000 email messages are generated by bugzilla.
> This is the first time (that I'm aware of) that a
> browser manufacturer intentionally made a browser
> that does NOT show what the server is sending to me.
No, the first time was when Microsoft introduced content-type sniffing.
> Frankly, if you're going to look at a website with
> a Chinese URL, you're going to know Chinese anyway.
Not if you're a browser developer attempting to reproduce a bug someone filed...
> Maybe if the Mozilla people are so injured
They are not. Please bother to read the blog that article was quoting, instead of beliving the out-of-context quotes you're given.
And there has been tremendous discussion about ways to improve generated by this. Please research before you flame, ok?
Well, lessee...
1) AOL Communicator is a pet project of a AOL VP who hates Netscape and wants the division to disappear. It's not clear to me how he thinks Gecko will get maintained after that.
2) Mozilla developers developed XUL because it makes UI development a lot faster and easier than using WxWindows.
The real problem Mozilla is facing right now, imo, is not the UI toolkit but the fact that Gecko is likely to be very much obsolete in 2-3 years unless a good deal of major work happens in the very near future...
No, what needs to change is the deplorable lack/inadequacy of public transportation that makes driving so necessary...
The main reason is that MSVC++ produces much smaller (and faster) code than g++ does. This is especially true because g++ 2.9x is being used, with only -O (not -O2, because that produces buggy code) optimization.
Moving to gcc 3.2 (once the Sun people get off their friggin' asses and compile Java with it) will help perf and footprint a lot (15% improvement or so last I heard).
> It's a challenging movie that asks questions
> without providing answers.
If it failed to do that it would _really_ be crap, since the whole point of Solaris (the book) is such questions... The point is, the questions it's asking are not nearly as challenging as the ones that it _could_ be asking (and that that book _does_ ask).
Some developers never test their changes, yes. I've seen people check in stuff that they obviously did not compile (it failed to build on _every_ supported Mozilla platform) much less test.
Animated gifs in a web browser? Remote display of a user typing, etc? Do those involve state changes in your architecture?
Quite correct. Mozilla.org does not provide end-user support; imo anyone who has issues understanding what the above SSL warning means would have issues using Mozilla in general. (Without support from some entity like their OS distributor, of course.)
Emacs also has a very nice auto-save. The only problem is that revert-buffer needs to be used _very_ rarely, while saving is so common I now hit C-x C-s at intervals without thinking (which _sucks_ in web browsers).
Fundamentally, there is no reason why revert-buffer can't use a temp file somewhere like auto-save does now, with auto-save writing to the main file. That would make a lot more sense, in fact....
IE/Mac and IE/Windows have nothing to do with each other. IE/Mac has typeahead find and has for a long time (and is generally a much better browser than IE/Windows).
The core group is not working on IRC Chat or Composer (except insofar as textareas need to work). IRC Chat was initially done by one person and is now maintained by three people or so.
That's how open source software works. Someone wanted an IRC client? They wrote one. If that's what they want to spend their time on, who's to stop them?
The number of people who know enough about the view manager to fix that clipping bug is about... 2. Of these two, both are full-time students (one's a grad student who spent the summer actually trying to make progress on his thesis). So they just haven't had the time to get into this problem....
Use the net installer.
Um... this is a _web_browser_. It happens (unfortunately) to come with an HTML editor. Are you using that to edit XML? Because that would be a little odd, no?