Slashdot Mirror

Microsoft VBScript runtime error '800a000d'

Type mismatch: 'CInt'

E:\INETPUB\WEBSITES\YIL\COLUMNS\../ssi/ssiASP.as p, line 83

This is not what Tim Berners-Lee intended...

What should be the most popular bug is this one, as it is preventing the moz team from cleaning up this other one.

What should be the most popular bug is this one, as it is preventing the moz team from cleaning up this other one.

What I find funny is you guys look at people using MSFT by choice as a problem. Aren't OSS/linux cult people by nature pro-freedom-choice. So if a user CHOOSES to use windows isn't that a good thing? I thought the gloves only come off when they have no choice?

Once I was talking with one of my friends and I asked him:
- Why do you use Windows?
- Well, isn't it the best choice? - he replied, so I asked him:
- How many different operating systems have you tried, so you can say which one is the best?
He said:
- None, but everyone I know told me to use Windows.
So I asked:
- How many different operating systems have everyone you know tried, so they can say which one is the best?
After few seconds of silence, he asked me:
- Can you help me installing Linux?

He had no problem with understanding my point because he's a musician composing, playing and listening to technically very difficult music, while most of people listens to pop music, so he knows that whenever you find that you are on the side of the majority, it is time to pause and reflect.

Some time after that, he convinced his father to try using Linux and Apache on one of his company's servers, then went the MySQL in the place of MS-SQL and even large part of the desktops were switched to diskless X terminals. The choice was obvious because of the lower cost (licenses, maintenance, backups, uptime, hardware requirements, etc.) but he didn't know he had that choice in the first place, no one had ever told him and that was the problem.

The problem is that I don't know many people who've chosen Windows, they usually just wanted a PC. I have yet to see anyone who can't work on my Debian boxes with Window Maker and Mozilla or Galeon. My parents use it and my sister uses it (now she has in her resume that she has experience with GNU/Linux and X11 environments, it looks very impressive to employers).

So that's what I do, I just give them a choice.

And don't tell me that most of people can't install and configure Debian, because most of people can't install and configure Windows either, they bought it preinstalled. We could talk about the choice you fight for, when I can go to a large computer store and buy a preinstalled working Debian box. Until then, please don't tell me about choice.

If you have a bugzilla account, head on over to
http://bugzilla.mozilla.org/show_bug.cgi?id=22687 and vote for what is probably the singles most popular bug there is. They need a framework which allows folks to plug in something like GPG at will. Plenty of work went into trying to get somewhere without any luck.

If you have an account at Mozilla's Bugzilla, vote for this bug here.

If you have an account at Mozilla's Bugzilla, vote for this bug here.

There's a pretty old bug (really a feature request) open in Mozilla's bugzilla for adding NTLM authentication. One day soon, maybe!

I am posting this on Slashdot under the yEnc Article, news.software.nntp, and also will CC it to both Jeremy Nixon and also Jürgen Helbing

I like the idea of bringing down the overhead of binary messages. With probably over 100GB? per day of binaries on all the newsgroups, this probably means a drastic 40GB reduction (albeit probably temporary as Jeremy Nixon mentioned) which means a lot of saved bandwidth on servers and also faster downloads for end users our favorite digital media (whatever that may be ;-). I feel this is a good start - though maybe a little rushed. I have to thank Jürgen for bringing the inefficiencies of MIME to the forefront of discussion even though he might have created a little extra work for developers. I also agree with Jeremy that yEnc should be stamped out in place of moving this into MIME.

I would first like to say: From the involvement I have seen from Jeremy with Usenet (especially news.software.nntp) and nntp software, I would be insane to say that I know more than or even close to what he knows. In fact, I work on the browser portion of Mozilla (as a volunteer) and know little about the underlying code of the Mail-News portion (nor do I even use it because its still very beta, and doesn't do what I need from a Usenet client). I am also not very knowledgeable on the deep-down guts of Usenet. I am a regular user of Usenet though, and have a little knowledge about how the news system works, so I feel that gives me a right to talk about yEnc from a more general standpoint than one possible from someone with Jeremy's experience. But I've decided to start expanding my experience into Mail-News and I'm thinking about implementing yEnc for Mozilla (even though I have a million other projects I'm working on).

From Jeremy's article:

>Unfortunately, with the discussions being fragmented in many newsgroups, the people
>who will ultimately determine the acceptance (or non-acceptance) of yEnc -- the end-
>users -- are largely unaware of the issues and problems raised by this situation.

I respectfully disagree that it is the end-user's decision.It is developers' decisions whether or not it becomes popular. Otherwise, we will have people continue to "spam" the groups with yEnc messages supported by only a couple clients. The people that have those clients will be happy and continue to post in that format, leaving out the people using other clients from those postings. This will never end, and the only solution is that everyone switch to the same client, ignore the postings as much as possible, or quality clients (which hopefully will one day include Mozilla Mail-News) support yEnc (at least on a read basis) so that no one will be left out of yEnc. It almost seems like developers have no choice now if they want to stay competitive in the Usenet arena. Good or bad? I think good in the long run, although it is currently a headache for developers.

>My objection to yEnc is because it was done poorly, not because it was done by
>Jürgen, and I certainly have nothing against him. Had he done it right, I would be
>thanking him right now.

I agree that yEnc seems like a wimp compared to MIME. Of course, this isn't the end of the world and I think it might be a good impetus to whip some people into action. I imagine that Jeremy, with his experience, Jürgen, and others can get together and majorly revamp the MIME standard, throwing out 7-bit encoding, including every new technology that has been thought of since its inception, making it easily identifiable as something separate from the old standard, and renaming it.

> And the bandwidth savings? That's an illusion. A smaller encoding scheme gives
> us exactly one benefit: faster downloads and uploads for the users. It is not going
> to make Usenet smaller. It is not going to allow servers to increase retention. Do
> you really think people aren't going to post more, if they can do it faster? Of
> course they are. They're always going to post more, with or without yEnc. And,
> with yEnc, they are even more likely to post more, because posting the same
> amount of material will take a shorter time, and because people who can't use
> yEnc will ask for reposts in uuencode. [I actually see this happening]

> The growth of Usenet volume is more or less exponential, and has been for quite some
> time. So let's just say I'm wrong > about people and they really will post less. Let's say
> that, overnight, all of the binaries on Usenet start getting posted in yEnc, and people
> post exactly the same amount they would have posted with uuencode, resulting in less
> total volume. All you have done, in that far-fetched scenario, is create a one-time
> volume savings. Usenet will continue to grow at the same rate it has been growing, and
> after a few months, it will be just as large as it was before. And it will get bigger from
> there. So all you have done is moved the graph back by a few months. Big deal.

Personally, I think that Usenet has gotten way too large to have all the newsgroups (or a large portion of them) on every server and needs to be redesigned (possibly with a more distributed system). That's another issue though.

> Programmers of Usenet software now have to implement yEnc in their code.
> Not just once, either. The specification is, as I write this, up to version 1.3, and
> there will be future revisions. So everyone has to go back and update their code
> every time the spec is updated. And they don't just have to change it, they have to
> continue to support the older spec as well, because updates to a new version won't
> happen overnight. And because the spec is imprecise, programmers are forced to create
> and maintain even more ugly [ Pretty :-) ] code in their software, when they could be
> spending time making more worthwhile improvements. There is a good reason for
> new standards to be discussed at length and incorporate feedback from experts - so
> that you don't have to keep going back and fixing it. And, even when something better
> comes along, all that yEnc code can't just go away; it will still be there, and still have to
> be maintained. People won't stop using yEnc overnight. It would take years to become
> uncommon.

I'm willing to waste a little of my time implementing it if it will stir some people into action. We need some kind of standard out there that can warrant the throwing away of every other encoding standard out there.
Anyone willing to undertake such a project? If there is a standard that replaces all the current standards, I imagine that yEnc, UUEncode, Base64 would phase out over time. A more naive wish is there could be an industry-wide
agreement to rip out all the other standards from their code, but I know the chances of that happening are slim.

Anyway, I say for Jeremy the old adage, "If you want something done right, you have to do it yourself". Jeremy, why don't you organize a group to oversee the development of a new all-inclusive MIME
standard? Is there any point to leaving the 7 bit aspects of MIME in there? Why aren't they ripped out (A question from someone who hasn't looked at the mime standard :)?

> Now, he seems to be planning to update the spec to include a means of using yEnc
> with MIME, which is the way everyone has told him it should be done. But he says
> he's going to do it within a few weeks! You can't add something to MIME in a few
> weeks, and there are good reasons for that. So, in reality, what he may be planning to
> do is bypass the standards process and simply publish a specification.

> There are two small problems (two that I have found, at least) with the MIME spec
> which would need to be addressed before the creation of a yEnc transfer-encoding.
> Why was MIME ignored for yEnc in the first place? Jürgen has said that MIME is
> not suitable because not all newsreaders support it, or support it fully. Does this
> make sense? You can't use MIME because it's not universally supported, so instead
> you create something new which isn't supported by a single newsreader in existence?

It appears that things are moving too slowly for his liking. This makes me think of huge multinational corporations that just lumber along and don't get anything accomplished but arguing and fighting. This (along with squelching
all competition) causes a slowdown in the growth of technology. I have no clue if that is the case with the MIME group, but it appears that Jürgen would like things to go a little faster. I definately agree with him on this, since I am
getting sick of all the messed up multipart postings I see on Usenet, and if the new changes being proposed to MIME can fix that (MD5 checksums, etc), then I would like to see that implemented as soon as possible. Since I don't have
the experience to do that and would rather not throw myself into yet another project, I hope people with experience can get the ball rolling. From my look at Google Groups, it seems that these things have been talked about for ages.
Why can't we have a little less talk and a little more action? From my experience on the Mozilla project, I see that people can sit discussing something for years. Sometimes, it's better to take the bull by the horns and try to - even
if it doesn't satisfy everybody - actually do something. For me, this means implementing something that has been talked about and discussed about forever because no one wants to (or has the time to) sit down and come up with a detailed proposal on how it should be accomplished.

> If you agree with me, what can you do to help? If you are the author of a
> Usenet newsreader, you probably have to implement yEnc at least for decoding

Sounds like a very good idea. I will propose this for Mail-News.

yEnc bug on bugzilla.mozilla.org

I have been looking through the binary newsgroups (as I am a regular lurker on many groups) and have been seeing all the people moaning about yEnc, and I can't say I blame them, as I have been moaning silently, also. That's the main reason I am planning on implemting this for Mozilla. That would leave one other thing before I was willing to switch from Outlook Express: Multipart message decoding (Hopefully better than OE's wimpy support), for which I have written a lengthy preliminary spec but don't have time to implement myself - Multipart messages bug.

Being a Mozilla developer, I would like nothing more than to use Mozilla's own software for news, and I will be caught between a rock and a hard place if Mozilla supports yEnc and not multipart decoding, and Outlook Express
supports multipart decoding and not yEnc (at least until people stop posting yEnc messages).

I am posting this on Slashdot under the yEnc Article, news.software.nntp, and also will CC it to both Jeremy Nixon and also Jürgen Helbing

I like the idea of bringing down the overhead of binary messages. With probably over 100GB? per day of binaries on all the newsgroups, this probably means a drastic 40GB reduction (albeit probably temporary as Jeremy Nixon mentioned) which means a lot of saved bandwidth on servers and also faster downloads for end users our favorite digital media (whatever that may be ;-). I feel this is a good start - though maybe a little rushed. I have to thank Jürgen for bringing the inefficiencies of MIME to the forefront of discussion even though he might have created a little extra work for developers. I also agree with Jeremy that yEnc should be stamped out in place of moving this into MIME.

I would first like to say: From the involvement I have seen from Jeremy with Usenet (especially news.software.nntp) and nntp software, I would be insane to say that I know more than or even close to what he knows. In fact, I work on the browser portion of Mozilla (as a volunteer) and know little about the underlying code of the Mail-News portion (nor do I even use it because its still very beta, and doesn't do what I need from a Usenet client). I am also not very knowledgeable on the deep-down guts of Usenet. I am a regular user of Usenet though, and have a little knowledge about how the news system works, so I feel that gives me a right to talk about yEnc from a more general standpoint than one possible from someone with Jeremy's experience. But I've decided to start expanding my experience into Mail-News and I'm thinking about implementing yEnc for Mozilla (even though I have a million other projects I'm working on).

From Jeremy's article:

>Unfortunately, with the discussions being fragmented in many newsgroups, the people
>who will ultimately determine the acceptance (or non-acceptance) of yEnc -- the end-
>users -- are largely unaware of the issues and problems raised by this situation.

I respectfully disagree that it is the end-user's decision.It is developers' decisions whether or not it becomes popular. Otherwise, we will have people continue to "spam" the groups with yEnc messages supported by only a couple clients. The people that have those clients will be happy and continue to post in that format, leaving out the people using other clients from those postings. This will never end, and the only solution is that everyone switch to the same client, ignore the postings as much as possible, or quality clients (which hopefully will one day include Mozilla Mail-News) support yEnc (at least on a read basis) so that no one will be left out of yEnc. It almost seems like developers have no choice now if they want to stay competitive in the Usenet arena. Good or bad? I think good in the long run, although it is currently a headache for developers.

>My objection to yEnc is because it was done poorly, not because it was done by
>Jürgen, and I certainly have nothing against him. Had he done it right, I would be
>thanking him right now.

I agree that yEnc seems like a wimp compared to MIME. Of course, this isn't the end of the world and I think it might be a good impetus to whip some people into action. I imagine that Jeremy, with his experience, Jürgen, and others can get together and majorly revamp the MIME standard, throwing out 7-bit encoding, including every new technology that has been thought of since its inception, making it easily identifiable as something separate from the old standard, and renaming it.

> And the bandwidth savings? That's an illusion. A smaller encoding scheme gives
> us exactly one benefit: faster downloads and uploads for the users. It is not going
> to make Usenet smaller. It is not going to allow servers to increase retention. Do
> you really think people aren't going to post more, if they can do it faster? Of
> course they are. They're always going to post more, with or without yEnc. And,
> with yEnc, they are even more likely to post more, because posting the same
> amount of material will take a shorter time, and because people who can't use
> yEnc will ask for reposts in uuencode. [I actually see this happening]

> The growth of Usenet volume is more or less exponential, and has been for quite some
> time. So let's just say I'm wrong > about people and they really will post less. Let's say
> that, overnight, all of the binaries on Usenet start getting posted in yEnc, and people
> post exactly the same amount they would have posted with uuencode, resulting in less
> total volume. All you have done, in that far-fetched scenario, is create a one-time
> volume savings. Usenet will continue to grow at the same rate it has been growing, and
> after a few months, it will be just as large as it was before. And it will get bigger from
> there. So all you have done is moved the graph back by a few months. Big deal.

Personally, I think that Usenet has gotten way too large to have all the newsgroups (or a large portion of them) on every server and needs to be redesigned (possibly with a more distributed system). That's another issue though.

> Programmers of Usenet software now have to implement yEnc in their code.
> Not just once, either. The specification is, as I write this, up to version 1.3, and
> there will be future revisions. So everyone has to go back and update their code
> every time the spec is updated. And they don't just have to change it, they have to
> continue to support the older spec as well, because updates to a new version won't
> happen overnight. And because the spec is imprecise, programmers are forced to create
> and maintain even more ugly [ Pretty :-) ] code in their software, when they could be
> spending time making more worthwhile improvements. There is a good reason for
> new standards to be discussed at length and incorporate feedback from experts - so
> that you don't have to keep going back and fixing it. And, even when something better
> comes along, all that yEnc code can't just go away; it will still be there, and still have to
> be maintained. People won't stop using yEnc overnight. It would take years to become
> uncommon.

I'm willing to waste a little of my time implementing it if it will stir some people into action. We need some kind of standard out there that can warrant the throwing away of every other encoding standard out there.
Anyone willing to undertake such a project? If there is a standard that replaces all the current standards, I imagine that yEnc, UUEncode, Base64 would phase out over time. A more naive wish is there could be an industry-wide
agreement to rip out all the other standards from their code, but I know the chances of that happening are slim.

Anyway, I say for Jeremy the old adage, "If you want something done right, you have to do it yourself". Jeremy, why don't you organize a group to oversee the development of a new all-inclusive MIME
standard? Is there any point to leaving the 7 bit aspects of MIME in there? Why aren't they ripped out (A question from someone who hasn't looked at the mime standard :)?

> Now, he seems to be planning to update the spec to include a means of using yEnc
> with MIME, which is the way everyone has told him it should be done. But he says
> he's going to do it within a few weeks! You can't add something to MIME in a few
> weeks, and there are good reasons for that. So, in reality, what he may be planning to
> do is bypass the standards process and simply publish a specification.

> There are two small problems (two that I have found, at least) with the MIME spec
> which would need to be addressed before the creation of a yEnc transfer-encoding.
> Why was MIME ignored for yEnc in the first place? Jürgen has said that MIME is
> not suitable because not all newsreaders support it, or support it fully. Does this
> make sense? You can't use MIME because it's not universally supported, so instead
> you create something new which isn't supported by a single newsreader in existence?

It appears that things are moving too slowly for his liking. This makes me think of huge multinational corporations that just lumber along and don't get anything accomplished but arguing and fighting. This (along with squelching
all competition) causes a slowdown in the growth of technology. I have no clue if that is the case with the MIME group, but it appears that Jürgen would like things to go a little faster. I definately agree with him on this, since I am
getting sick of all the messed up multipart postings I see on Usenet, and if the new changes being proposed to MIME can fix that (MD5 checksums, etc), then I would like to see that implemented as soon as possible. Since I don't have
the experience to do that and would rather not throw myself into yet another project, I hope people with experience can get the ball rolling. From my look at Google Groups, it seems that these things have been talked about for ages.
Why can't we have a little less talk and a little more action? From my experience on the Mozilla project, I see that people can sit discussing something for years. Sometimes, it's better to take the bull by the horns and try to - even
if it doesn't satisfy everybody - actually do something. For me, this means implementing something that has been talked about and discussed about forever because no one wants to (or has the time to) sit down and come up with a detailed proposal on how it should be accomplished.

> If you agree with me, what can you do to help? If you are the author of a
> Usenet newsreader, you probably have to implement yEnc at least for decoding

Sounds like a very good idea. I will propose this for Mail-News.

yEnc bug on bugzilla.mozilla.org

I have been looking through the binary newsgroups (as I am a regular lurker on many groups) and have been seeing all the people moaning about yEnc, and I can't say I blame them, as I have been moaning silently, also. That's the main reason I am planning on implemting this for Mozilla. That would leave one other thing before I was willing to switch from Outlook Express: Multipart message decoding (Hopefully better than OE's wimpy support), for which I have written a lengthy preliminary spec but don't have time to implement myself - Multipart messages bug.

Being a Mozilla developer, I would like nothing more than to use Mozilla's own software for news, and I will be caught between a rock and a hard place if Mozilla supports yEnc and not multipart decoding, and Outlook Express
supports multipart decoding and not yEnc (at least until people stop posting yEnc messages).

Just thought some of you Mozilla fans might be interested to know that there is already an open bug in bugzilla 119964 to support yEnc in Usenet postings.

Recent posting indicate that some of fellow Moz contributors may be taking this issue and fixing it ahead of the planned "future" date already assigned by the developer - if any of you can do this fairly quickly, i'm sure the rest of us MailNews users would appreciate your efforts!

perhaps you can back up the "buggy enough" swipe by referring to actual bugs you personally ... logged in bugzilla.mozilla.org? Those such as myself who use Mozilla email every day under extremely heavy load with now great performance and no crashes for many months may otherwise not believe you gave it a real try.

First of all, the Netscape mail client is compatible with AOL mail servers, and after reading the Mozilla mail spec I have no idea whether this is part of the Mozilla mail client as well or particular to Nestcape, so I have no idea whether to even report a bug. Further, when you work for AOL, I think complaining to IT is pretty much as far as you're required to go. AOL knew about these issues and funds the vast majority of Mozilla programmers.

Also, you might use Mozilla every day under extremely heavy load, but are you doing so connecting to AOL servers? Have you ever clicked Reply only to end up staring at a blank new message? Have you ever had your keyboard shortcuts mysteriously stop working? Do you know that when you have a POP account alongside an AOL account the POP account ignores the 'automatically check every X minutes' setting? Have you ever tried selecting "Netscape Mail" or "Netscape Navigator" from the Apple menu when one of those programs was already open and seen the laughable result? Do you know how incredibly SLOW Netscape mail feels (over POP or IMAP or AOL) next to outlook express?

Do you use Mozilla on a Mac, which (go figure) is a very popular platform within Time Warner? Have you ever had Netscape mail decide it didn't like your configuration and crash every single time you tried to open it, requiring a total reinstall before it would even allow you back at the config panel?

You are so totally clueless. Ya, blame the users for this cruddy software; in the meantime I'll gladly hop back to Outlook Express and curse the day I ever gave Mozilla a try (since you ignored the fact that half of this is a problem with AOL servers, I'll go ahead and ignore that too).

• For the record:
• flash: don't want
• shockwave: see flash
• java: mostly harmless
• noisy web pages: don't want
• quicktime: don't want integrated
• real player: don't want integrated
• vrml: you've got to be kidding..

You can patch Mozilla 0.9.9 to get WMP plugins to work. This is (sort of) mentioned in the article. The patch is here and the bug report (resolved) is here. And it works fine for me, moreover...

You can patch Mozilla 0.9.9 to get WMP plugins to work. This is (sort of) mentioned in the article. The patch is here and the bug report (resolved) is here. And it works fine for me, moreover...

Seems that BHO is a Micro$oft technology. Yet another reason to stay away from IE. God, thank you for bessing us with this.

I worked for AOL when they "acquired" SUN Microsystems.

Well, you must have been on crack at the time, because that never actually happened.

I used to work for Sun, and what did happen was a "strategic alliance" between Sun and AOL/Netscape. Yeah, it was so great that whenever we'd call for support they'd refuse to answer the phone if they knew it was us calling.

From what I've heard, there have been orders recently within Sun that no official business is to be done over any AOL products (the Instant Messenger especially). But that's just a rumor.

BTW, Netscape 4 is garbage, as we all know, and the iPlanet server disgusts me. It ate our configuration files once. As far as Netscape 6 goes, why would you use it when you can use the version without ads and branding? (Sorry, had to rant for a paragraph there.)

The easiest way to remove it is to click here or install this.

Actually, Mozilla now has the backend for P3P in place. It isn't ready for end users yet, but I believe most or all of it will be in place for 1.0. See the Mozilla bug relating to P3P here.

These are the ingredients to make large projects successful from a technical point of view. At the company I work for, we have literally hundreds of people working in the same source tree using P4. It manages merges, versioning, and works flawlessly over the internet (well VPN anyway). It is also much, much faster at syncing to the the depot than CVS because the server keeps track of those files that you are editing and does not need to do diffs with the local filesystem. This is very helpful during crunchtime where you might want to sync serveral times a day (and you have about 10000 files in the system). Also, until your locally edited files are resolved with changes in the depot you cannot submit them, so you don't have the problem of ordering patches properly.

For the second part, I highly reccommend that you have automated build and tests that run after changes have been submitted. You can see how this is done en mass on the mozilla.org site. Also, developers should have access to the same build and test infrastructure on their machines so they can do the build and test before they check in their code.

Finally, you need a good bug tracking system. You might try Bugzilla.

Good luck,
Sam

One solution to avoid patching problem is to use continuous integration. It's an integration technique that builds your source multiple times a day, getting all the latest source code from the CVS tree, and building from that code. If anything fails, the offending developer gets warned. Mozilla uses the same thing, calling it TinderBox. It's one of the principles of Extreme Programming, and seems to work quite well at our company.

It is nice to see a technology demo of this tool, but mozilla already has a tool for finding memory leaks (among other things) called spaceTrace:

which you can find out about here

... memprof is based on the same Boehm [garbage collector] that Geodesic is, though Geodesic's is a closed source fork.

Which is pretty funny, because the Boehm-Demers-Weiser garbage collector is already used (cache) with Mozilla (cache) to detect leaks.

Also take a look at http://bugzilla.mozilla.org/show_bug.cgi?id=89853, the Mozilla bug assigned to getting the bastards to support Mozilla.

Right now, I'm of the opinion Capital One are within their rights not to support a version 0.x browser. As soon as the 1.0 release candidate comes out (next month), I'll be letting them know that they better allow users of 1.0 in or I'm cutting up my credit cards.

It's not as if EVERY COMPETITOR OF THEIR'S IN THE COUNTRY isn't trying to get my business.

Anyone want to recommend any Mozilla-friendly credit card companies out of interest?

0.99 is out!

But remember that all good software never reaches 1.0!

According to Tech Evangelism bug 89853, this problem hasn't been fixed yet. From reading the bug report, it does look like they're trying to solve the problem. Probably the prospect of AOL using Gecko will motivate them some more!

However, the major hold up is that my bank refuses to allow me to use it - the site became inaccessible to modern Netscape/Mozilla browsers curiously enough at about the same time the whole thing went .asp-based.

If you find a page that doesn't work well with Mozilla, you can file a Tech Evangelism bug report. The Intel site does have bug 113099 reported against it. If this is the bug you're experiencing you can vote for it, or you can go report your bug.

If you find a page that doesn't work well with Mozilla, you can file a Tech Evangelism bug report. The Intel site does have bug 113099 reported against it. If this is the bug you're experiencing you can vote for it, or you can go report your bug.

If you're talking about Komodo from ActiveState, then they're using XUL (I don't think Gecko is used IMO)

Take a look at all of the DaimlerChrysler passenger car websites such as Chrysler or Dodge. They all use layers and do not render correctly in Mozilla as a result.

Now consider the fact that 1450 is only the number of such sites that have been reported and that are still open. There have been many reported sites that have been closed simply because the Mozilla team sees no hope of convincing the webmasters to change their site!

Netscape announced this before the AOL acquisition. As a matter of fact, there was wide speculation that the Mozilla project would be shut down as a result. There is an e-mail from Steve Case on mozilla.org addressing this concern. To AOL's credit, they (AFAIK) let the project continue more or less as it was before. I know that there were some layoffs not long ago and many Netscape employees quit early on, but I don't think that these things had a lot to do with a lack of support from AOL. Someone please correct me if they know better.

The binary doean't seem to have TT font support compiled in. try "export NS_FONT_DEBUG=400" and the launch moz from the console. Watch for it to say something about "* not compiled in". It suggest this test in the docs here

"...most used piece of freeware on my windows machine (IE doesn't count...I only use it because of the google toolbar.)"

That, and IE isn't freeware - contrary to popular belief, you paid for it when you paid for your O.S. Microsoft didn't make it for nothing, and where do you think their money came from?

It's just a thought.

Oh yeah, and download mozilla and then go here and then download this. Click on it in mozilla and it will install their plugin for you. Then, don't use IE, and smile.

*kudos* to the guy who posted this before me, and definately to the Mozilla programmers who wrote it, i just installed their pseudo-toolbar and it is definately cool.

You can add your own toolbars for any search engine. I have several samples for Mozilla on my webpage. I also include a very brief description on how to add other search engines, and/or add them to IE.

-- Agthorr

.IfyouareusingMicrosoftInternetExplorer .thenpageswrittenlikethis .withnolinks .andwordsseparatedonlybynonbreakingspaces .andspacedots .willberenderedcompletelyononeline .asyouseehere .ThusPAGEWIDENINGISBACK .andthereislittleausercando .exceptmovetoadifferentwebsite .Ofcourserealwebbrowsershavefixedthesebugs .alongtimeago .Sousetherecent.9.9releaseofMozilla

Therefore Mozilla really needs to have this feature added to Googlebar to level the field.

If you have a bug to report, or a suggestion to make, can you take it to here ?

While I agree with your sentiment, I would submit that if Mozilla is a commercial project (AOL's paying for it), then the Mozilla team (not necessarily developers, could be someone with secretarial skills) should monitor Slashdot and other discussion sites when Mozilla is being discussed.

I used to do this at my former employer, and was appreciated both by management and customers.

someone claimed this was new in .9.8, too. it wasn't new then, either.

I really hope they get over the whole communist-like theme. Those red stars with yellow borders (Help->About Mozilla) do not impress, and I suspect those who have suffered at the hands of communist regimes would take offence.

I much preferred the cute little green dinosaur, briefly visible on the splash screen.

Not a big issue for me, but others on the Mozilla mailing lists seem to be up in arms about it.

.
.

I really hope they get over the whole communist-like theme. Those red stars with yellow borders (Help->About Mozilla) do not impress, and I suspect those who have suffered at the hands of communist regimes would take offence.

I much preferred the cute little green dinosaur, briefly visible on the splash screen.

Not a big issue for me, but others on the Mozilla mailing lists seem to be up in arms about it.

.
.

Does that mean that developers marked 1998 bugs as duplicates, fixed 1, and marked 1 as non-reproducible?

ROLFMAO! The 2,000 bugs fixed number is in fact a complete lie, for pretty much the reason you stated. Take a look at the current bug chart. Notice that the current count is not even close to 2,000 bugs lower than last month. It's not lower at all.

I like the way Asa can just come on here and say any damn fool thing he likes, be as insulting as he likes, and still get modded up as some sort of infallible guru.

Way before that actually...

The way this particular behaviour works first appeared in 0.9.4, but earlier versions of not allowing windows to open on their own existed before that. Information like this on how to set certain options in your prefs.js is always the main reason for me to read the release notes. Some true gems in there every now and then.

How about voting for fixing the bugs like number 55583 before voting up new features. The inability to view source of non-static pages is IMHO a showstopper bug, at least for anybody who actually wants to develop websites using Moz...

Agreed. It's not to say that I don't want to see a lot of those other features, yesterday rather than today, but not being able to view the generated source of any page that is created with information from a submitted form is highly annoying.
And I personally still haven't figured out what is the least worse of the workarounds... saving the page and looking at that source, or actually opening Netscape 4.x for testing. (The only time I ever open another browser other than during the final testing of whatever site I've just created.)

It must know I love it, because whenever I tell it to stay down for a minute it just keeps popping right back up!!!

... I'd still really love to see ROT-13 encoding/decoding in the mailer a la netscape.

How about voting for fixing the bugs like number 55583 before voting up new features. The inability to view source of non-static pages is IMHO a showstopper bug, at least for anybody who actually wants to develop websites using Moz...

You really think modding a slashdot comment up will make ROT-13 be implemented sooner?

Sorry, but you're in the wrong forum. What you're really looking for is Bugzilla, "modding up" is called voting, and the relevant bug is #66822 . It is currently targeted at Mozilla 1.1.

You really think modding a slashdot comment up will make ROT-13 be implemented sooner?

Sorry, but you're in the wrong forum. What you're really looking for is Bugzilla, "modding up" is called voting, and the relevant bug is #66822 . It is currently targeted at Mozilla 1.1.

You really think modding a slashdot comment up will make ROT-13 be implemented sooner?

Sorry, but you're in the wrong forum. What you're really looking for is Bugzilla, "modding up" is called voting, and the relevant bug is #66822 . It is currently targeted at Mozilla 1.1.