Links Toolbar LandedWednesday October 3rd, 2001Gervase Markham writes: "The Links Toolbar from bug 87428 has finally landed, bringing us ever-closer to full support for HTML 2.0. You'll see it in this morning's builds. The auto-show is still in development over in bug 102832. Good places to try it out are Bugzilla buglists, the W3C, htmlhelp.com and many machine-generated manuals or documents, such as the GNU Make manual." It appears that the Links Toolbar does not play nicely with tabs. That is too bad. I love links about as much I love tabs. I will file a bug if one is not filed already. Oh yeah! First the tabs, now links. Wonderful! Mozilla is really shaping up, getting new stuff that Explorer does not have. When 1.0 is finally launched these features really have to be pushed to the public. Many ordinary users will probably want to switch to Mozilla (or Netscape) when they see this stuff. Now I just have to get around to adding link info to all my own pages. Some of them can really profit from this functionality. Now, what I'd like to see is a way to make choice of alternate stylesheets stick from one page to another on the same site. As things stand now the alternate stylesheet functionality is pretty useless. If a big site uses the same stylesheets for all pages, a visitor has to remake his stylesheet choice for every page, again and again and again... Not much sense in that. (Sorry about the rant. Don't stop 1.0 just for this...) show an explaination and you can download all the files needed to check it too. Complexspiral Demo http://www.meyerweb.com/eric/css/edge/complexspiral/demo.html files you can save are here: http://www.meyerweb.com/eric/css/edge/complexspiral/ #105 Re: cool CSS2 & stylesheets working web example:by bertilow Saturday October 6th, 2001 7:06 AM Hey! That demo page is beautiful, and has very good info. But it does not adress the problem I mentioned. That's just one page, it does not link to any other page _that uses the same set of alternative style sheets_. If it would do so, and if I would first change to one of the alternative styles, and then click on a link to another page that has the same set of style sheets, that second page would load with the default style, and I would have to manually select my preferred style sheet once again. There is no saving of state going on. For that you'd have to use some kind of client scripting solution. And that makes this whole Mozilla feature very limited for practical use. check out this page; he is an expert in CSS and he will probably post more here: http://www.meyerweb.com/eric/css/edge/ matter of fact, I'll ask him about your problem.. maybe he got some good info to share. Else then file a bug in mozilla for stylesheet state saving on a per site basis, cookies are the way to do that. Not much scripting involved if you write code that reusable in every page. and you can just do an @import, and also load external .css sheets that do more that just define styles, you can write JS in side of them too. I know that for a fact, because www.storagereview.com has a stylesheet that loads with JS code inside, I've see it. Next is the first page of many with table-less sites that use CSS2 for all their stuff, I bet there is some selectable stylesheet sites in here somewhere. http://www.webnouveau.net/index1.html I just picked this one out of the list with CSS2, not using selectable stylesheets, but another example. http://www.twistedmystic.com/ #150 Re: Re: Re: cool CSS2 & stylesheets working web exby bertilow Sunday October 7th, 2001 4:29 PM Yes, you can do all that stuff yourself. It's not too hard. But that's my point: The Mozilla support for alternative style sheets is by itself very limited, practically meaningless. If you want something useful, you'll have to write the whole machinery yourself. Perhaps I'll register this as a bug when Mozilla 1.0 has landed. It's not really that important. It can wait until a later release. http://terrapin-gardens.net/ here is an example of stylesheets changing my selection, Mozilla needs to save my selection over what the page loads. I chose stylesheet->none and loaded a new link from this site and it must be loading a new selection out of its css declaration. Mozilla should overide it with my selection. -Dman84 A bug (#102905) has already been submitted. That was quick. Go community. there's already a long list of bugs and features for the links toolbar ;) so check this link before you do anything. http://bugzilla.mozilla.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&short_desc=Link+toolbar&short_desc_type=allwordssubstr&long_desc=&long_desc_type=substring&bug_file_loc=&bug_file_loc_type=substring&status_whiteboard=&status_whiteboard_type=substring&keywords=&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&namedcmd=All+My+Bugs&newqueryname=&order=Reuse+same+sort+as+last+time I read through the 2 mian bugs listed and I still have not got a clue what this links toolbar is. Anyone care to educate me. I'm gonna go trawl *.ui The link toolbar gives a UI to most of the <link> tags functionality. Before today, the link tag in mozilla was only used to apply style sheets and alternate style sheets (View->Use Stylesheet). Now that the link tag has landed web page developers can tell the browser "The next page is page 2" "The previous page is the table of contents" "The table of contents is located here" etc etc... http://www.eightlines.com/links/ This is a page I made. In the code I have: <link href="http://www.eightlines.com/style.css" rel="stylesheet"> <link rel="start" type="text/html" href="../"> What this does is apply a stylesheet called style.css and now that the link toolbar is in I believe you'll see a button labelled "Top" become enabled. When you press it, the web browser will go to http://www.eightlines.com/ The only other browsers that I can think of that support the Link tag in this was are iCab for the Mac and Lynx. I just downloaded the build that is supposed to have the "Links" toolbar (2001100203), but I don't see it or how to activate it once I go to the pages specified. Maybe it is obvious and I'm just not seeing it. #7 Re: Could someone give a brief overview of the tooby tseng_mike Wednesday October 3rd, 2001 2:12 PM You need 2001100303 I just downloaded the build that is supposed to have the "Links" toolbar (2001100203), but I don't see it or how to activate it once I go to the pages specified. Maybe it is obvious and I'm just not seeing it. View > Show/Hide > Link Toolbar; it shows up as a little toolbar under the Home/Bookmarks ('Personal') toolbar with ^Top ^Up |<First <Previous >Next >|Last Document More buttons/menus (the last two are menus). These get their data from the <link> element : no, it's not just for stylesheets. It's a beautiful thing, and another killer reason for using Mozilla. I didn't have any trouble with the tabs and the links in 2001100303. It appears that you have to unview and review the toolbar to get it to work. To do this go to View|Show Hide|Link Toolbar and uncheck then recheck the item. This may not be the case but that's what seemed to work for me. --Asa Is there a way to put it ABOVE the bookmarks toolbar? I like it that way :) Jesse Bug 102832 http://bugzilla.mozilla.org/show_bug.cgi?id=102832 has r/sr/a and should be checked in shortly (I hope) :) - look for it in tomorrow's nightlies :) Stuart. I never really "got" why this was supposed to be so cool... until i clicked on the link to all the bugs open on the link toolbar... bugzilla supportshat it, my god is t helpful :) :) With the javascript debugger, tabbed browsing and the links toolbar, Moz is really pulling ahead of every other browser out there... even my skeptical girlfriend has started contemplating getting rid of ie. #17 Please let this and tabs be switched on in 0.9.5by DavidGerard Wednesday October 3rd, 2001 6:33 PM I know that neither <link> nor tabbrowser are finished yet. But PLEASE have these both switched on in 0.9.5 for some serious real-world beating around. We'll have these polished and wonderful while IE 6.1 (120MB service pack download, no doubt) is clunking away on them ... I've just set up bug 103053 to track various improvements to the Link Toolbar. How in the world do you set breakpoints in the JavaScript debugger? In the code view, just click in the blank space at the left side of the statement you want to set a breakpoint on. Venkman homepage http://www.mozilla.org/projects/venkman/ Project Overview http://www.mozilla.org/projects/venkman/venkman-overview.html User Guide http://www.mozilla.org/projects/venkman/venkman-walkthrough.html --Asa See http://bugzilla.mozilla.org/show_bug.cgi?id=103082 - "The links toolbar is causing a 2-3% impact on startup/new window and a 5% slowdown on page load times. The page load hit in particular is unacceptable." Foo :-( Would still be SO nice to have this in 0.9.5, if its performance hit can be rectified. A bug http://bugzilla.mozilla.org/show_bug.cgi?id=102992 has been filed to convert the Link Toolbar to XBL. That should sort out the performance problems. It looks like it's not going to make it into 0.9.5 though, so you'll have to wait until 0.9.6. Alex http://bugzilla.mozilla.org/show_bug.cgi?id=103097 which is probably where the majority of the page-load-time fixing will happen. 102992 is more about the new-window and startup time impact, which might take a bit longer to fix since it's not such a dramatically noticeable performance hit. Btw some work is going on in http://bugzilla.mozilla.org/show_bug.cgi?id=103082 which might just result in the toolbar getting added back to the build, turned off by default, for 0.9.5. This bug doesn't need votes, but if you know how to do page-load-time performance testing, confirmation that the patch does what it should do would be appreciated. In the same spirit, I've filed bug 103163 to remove Quirks Mode, probably the biggest cause of performance problems and code bloat in the entirety of Mozilla. Vote for it today! Although I agree in principle with you, I definitely do not support this in practice. Since quirks mode was added, things like banking applications and MS Exchange Web Interface have just started to work. And that is beautiful ;) If we want to have any chance at overtaking IE\\\'s market share, Mozilla needs to be script-compatible. I don\'t think that was his point exactly. Why should link toolbar get backed out for a 5% performance hit? What about the other 95%? It\'s basically getting grandfathered in no matter how shitty the code it. It\'s making it quite difficult to get this into the tree even though it implements a new and highly demanded feature. What high demand? The number of sites that uses this is so low, it's almost a joke. You're right; very few sites use it now. And no browser has really supported it before. Now that the people who've grabbed builds from the 3rd have seen it; a lot of us want it. I've started adding <LINK> tags to my personal site and plan on adding them to client sites now that there's a browser that supports more than just adding stylesheets. It's a very useful augmentation to a site's existing navigation, and I hope the Mozilla programmers get it reactivated as quickly as they can. <rambleMode> Having said all that, I agree that it should be shut off for now. Adding 5% to an already-slow program's start time is a Bad Idea. As to the 95% "shitty" code, a lot of it probably predates the current review process. Bad, slow code is why multiple people need to eyeball a patch before it gets checked in. The Mozilla crew has already re-written some bad code (imglib2, aka libpr0n; the new cache; etc) to make Mozilla faster. The problem with the old code is that someone needs to look through it carefully as it runs and file bugs where optimization can be done. I don't see that being the most exciting way to contribute to the project, and I don't think I would do it myself even if I had the programming skills. Can someone In The Know tell us what we can do if we just have a gut feeling that the browser is slow because of XYZ? We shouldn't just go filing bugs that say "Uh, I think this part's slow, or something" but it might be useful to get a better-trained person to look at a potentially problematic chunk of older code. </rambleMode> Sounds like you're looking for http://www.mozilla.org/performance/ --Asa Precisely. Anyone at Netscape.com who's so worried about performance they're backing out changes years in the making at midnight should either concentrate on that web page or just be fired. That's enough. I don't know where these fly-by-night engineers are being educated, but I've had it with their puerile shenanigans; enough's enough. Send them back to the tractor factory; the rest of us are using this codebase to serious purpose. greg, I don't know what your understanding of 'using this codebase to serious purpose' is, but waiting a grossly unnecessary additional 5% of time for *every* webpage to load is in my opinion definately not putting my time to good use or 'serious business'. In our company, developers actually cost money, and every second they spend waiting for page rendering to finish is a second wasted and not put to good use. We should always be right on top of performance issues; companies don't like their employees doing nothing. Besides, if we *ever* want to reach 1.0, we just can't keep on regressing. The closer we come to 1.0, the higher our standards should be. If we have to fix regressions with every few checkins, we'll never reach 1.0. cool....seems like for nearly every question about Mozilla there's already a page on mozilla.org Is there something like a sitemap for mozilla.org where I could find them? Or am I just blind and never really looked at the menu? Fine, you want a Web built of sites made to service HTML 1 or IE? Fine, go ahead, build it yourself. The rest of us who built the Web for serious purpose wish you well in your new life. MozillaNews, you know, the other Mozilla news site (no, not MozillaQuest, that's a Mozilla fiction site) has an article http://www.mozillanews.org/index.php3?article=12 from jesus x about Netscape's browser plans. Much of the article is speculation but it sounds plausible. We all know by now that Netscape took over the 0.9.4 branch to make eMojo, which until recently I belived was going to be the enterprise version of 6.1 (the original 6.1 was codenamed Mojo). Either I was wrong or Netscape's changed plans because recent references to Netscape 6.2 have appeared in Bugzilla. The article gives convincing evidence that 6.2 will be the next release and that there will be standard and enterprise versions of it. Compared to the improvements between 6.01 and 6.1, 6.2 will be less of an upgrade which makes me question why they don't just call it 6.11 or something. The article goes on to mention MachV, the next release after eMojo. It seems that it will be based on Mozilla 1.0 (but I remember a time when 6.0 was going to be based on 1.0) and the working title is Netscape 6.5. If you want to know more, do a search for "machv" on mozilla.org - it will bring up some interesting specs. The article suggests that Netscape will be concentrating on corporate users. It's not the first time they've done this: 4.x was very business-orientated (at least in the initial releases before they pulled Calendar and other stuff no-one used - NetCaster, anyone?). This is probably wise as corporate users want things like LDAP and IMAP support which Netscape has traditionally been strong on (Outlook Express can provide those things too but its security leaves something to be desired). Alex As much as I do like all those cool features and cool stuff getting added to Mozilla I wonder who is setting the priorities? There are still quite some features missing that were in NS4.x, and there are bugs where things dont work that did work in NS4.x. Nothing seems to happen with these bugs (some of them have been there for months or years). Is this really a good way to allocate ressources? My feeling is, that boring business users would maybe rather trade in basic functionality for one or the other cool feature. It was done almost entirely by external contributors. Gerv landed it and Hyatt did a little cleanup, but all the code was initially completed by 3rd parties. NS 4.x was written prior to a lot of standards. Mozilla does *not* support proprietary standards, only W3C ones (although how long it will be before they ditch the W3C in favour of open standards with the W3C contemplating/beginning to accept patents is interesting to contemplate). Thus, many things that don\'t work in Moz that used to work in NS are broken because they\'re not open standards, but proprietary ones. This is a Feature, not a Bug. If Moz renders your page properly, chances are very good that any other standards-compliant browser will, too. trelane2, I am not talking about legacy stuff: I am talking about the ability to quote the currently selected email/newsgroup article http://bugzilla.mozilla.org/show_bug.cgi?id=70478, the backward/forward bug that is still resurfacing now and then, the ability to move toolbars around and not just click them open/closed, preferences for movemail, and some other stuff I have encountered but cant remember now. With regard to standards/legacy stuff: I dont know whether dropping non-standard stuff is a good idea when it comes to acceptance by a broad audience, but I realize that this is the philosophy of how Mozilla developers want to go and I hope it wont backfire. But I am all for following standards even if I dont like and/or understand them :) This feature was 2 years in the making. It was supposed to make it into mozilla long ago (Before netscape released 6.0). It's also part of the HTML 2 standards. You want mozilla to support HTML 4 right? Well, they need to support HTML 2 first. >> It's also part of the HTML 2 standards. You want mozilla to support HTML 4 right? Well, they need to support HTML 2 first. << No, they don't. Look it up on the w3c site at http://www.w3.org/MarkUp/ and you'll see that HTML 2.0 is obsolete: "Note that with the release of RFC 2854, RFC 1866 has been obsoleted and its current status is HISTORIC." Here's what HTML 4.01 says about the LINK tag at http://www.w3.org/TR/html401/struct/links.html#h-12.3 : "Although LINK has no content, it conveys relationship information that may be rendered by user agents in a variety of ways (e.g., a tool-bar with a drop-down menu of links)." There is no requirement that they be represented by the user agent at all -- that's what the word "may" means. RFC's are very precise with language like "may," "should," and "must." I think it's more accurate to say that, like many immature engineering organizations, Netscape/Mozilla lacks the discipline to stop adding new things and just fix and polish what's already been added at the right stage of the project. Those of us who've been through this perennial engineering conundrum know that it's a recipe for shipping an unstable product, or never shipping at all. >>Here's what HTML 4.01 says about the LINK tag at (LINK) : "Although LINK has no content, it conveys relationship information that may be rendered by user agents in a variety of ways (e.g., a tool-bar with a drop-down menu of links)." There is no requirement that they be represented by the user agent at all -- that's what the word "may" means. RFC's are very precise with language like "may," "should," and "must."<< This argument is fallacious-see the comments at the bottom of bug 7954. The requirements imposed on user agents by HTML 4.01 are actually very small-a UA that didn't implement any SHOULDs wouldn't be much use. HTML 4.01 uses RFC-requirements language, but does it badly (much like it uses SGML). >>I think it's more accurate to say that, like many immature engineering organizations, Netscape/Mozilla lacks the discipline to stop adding new things and just fix and polish what's already been added at the right stage of the project. Those of us who've been through this perennial engineering conundrum know that it's a recipe for shipping an unstable product, or never shipping at all.<< Um, well, no. Free clues: 1) This wasn't written by Netscape people. It's been under development by outside contributors for quite some time (see bugs 2800 and 87428 for the gory details). 2) It was checked into the tree on 10/4/01, caused a performance hit, and was disabled because of it. It's now back in, modulo two performance patches and a couple of polish patches. IOW, the feature *WAS* halted because it was found not to be sufficiently polished; now it is. Please take the "you guys can't design and manage software" horse you rode in on and go back where you came from. (FWIW, a commentary on a similar UI feature is here: <URL:http://www.useit.com/papers/icab.html>) >> a UA that didn't implement any SHOULDs wouldn't be much use.<< It's not a "should," it's a "may". I quoted it directly. There is no HTML standard requirement for this feature. >> This wasn't written by Netscape people.<< It doesn't matter. Netscape people manage the source, and they let this checkin happen during feature freeze based on fallacious arguments about standards. Now a bunch of Netscape people are spending a ton of time working on evaluating this new feature and making determinations about it, time which they couild be using to drive down the upward-spiraling defect line. It's bad project management and it's hurting the software's chances of ever attaining a stable release. For reference to newbies out there, Strauss is talking crap - the defect curve (duh - a line can't 'spiral') isn't spiralling upwards. And he surely knows it. http://www.dictionary.com/cgi-bin/dict.pl?term=spiral v. spi·raled, also spi·ralled spi·ral·ing, spi·ral·ling spi·rals, spi·rals v. intr. 2. To rise or fall with steady acceleration. http://bugzilla.mozilla.org/reports.cgi?product=Browser&output=show_chart&datasets=NEW%3A&datasets=ASSIGNED%3A&datasets=REOPENED%3A&datasets=UNCONFIRMED%3A&links=1&banner=1 Q.E.D. Notice that the actual new bug line is STRAIGHT, as in constant, which is to be expected as this project climbs towards feature completeness. The _reported_ bug line is curving up, which is also to be expected as Mozilla get a bigger and bigger following and there are more people reporting (false and duplicate) bugs. Nice try though! :) As I said above, trying to make sense of the supposedly RFC-normative language in HTML4 is a canard; such language is much better suited to describing protocol handling than general UI. Regardless, the W3C Note Common User Agent Problems says that while HTML 4.01 does not specify definitive rendering for <link> elements, user agents should interpret them in useful ways. That's a very clear call for this feature. >>It doesn't matter. Netscape people manage the source, and they let this checkin happen during feature freeze based on fallacious arguments about standards.<< No, they checked it in because it had gotten an obscene amount of code review and looked like a safe patch. Did you even bother looking at bug 87248? None of the testers and reviewers noticed perf problems before this was checked in; I presume that the addition of the toolbar makes the *perceived* time appear the same (because there's a new bit of chrome that catches your eye as the page loads), but actually increased it a bit. Standards don't have Get-Into-The-Tree-Free cards. >>Now a bunch of Netscape people are spending a ton of time working on evaluating this new feature and making determinations about it, time which they could be using to drive down the upward-spiraling defect line. It's bad project management and it's hurting the software's chances of ever attaining a stable release.<< Huh? Netscape people are not spending "a ton of time" on this. jrgm saw a spike on his performance tests, re-ran them with and without the patch, and hyatt pulled it out. sballard, non-NS, produced several perf patches, including one that keeps it from using resources when disabled; hyatt saw that it was good, and the toolbar was put back in, disabled-by-default. I'd say that's fairly good for getting in a feature which is on a par with Print Preview for bugzilla votes (distributed across bugs 2800, 87428 and 103053). As things stand, there's absolutely no need for NS people to be "evaluating it and making determinations about it"-it's in the build, it works if you want it, and it doesn't hurt you if you don't. >> the W3C Note Common User Agent Problems says that while HTML 4.01 does not specify definitive rendering for <link> elements, user agents should interpret them in useful ways. That's a very clear call for this feature. << http://www.w3.org/TR/cuap "This document is a Note made available by the W3C for discussion only. Publication of this Note by W3C indicates no endorsement by W3C or the W3C Team, or any W3C Members. There is no commitment by W3C to invest additional resources in topics addressed by this Note.... "Although the HTML 4.01 specification does not specify definitive rendering or behavior for these link types, user agents should interpret them in useful ways. For instance, the start, next, prev, and contents link types may be used to build a table of contents, or may be used to identify the print order of documents, etc." So the actual status is not, as stated, that this is required by the HTML standard. Someone's opinion piece says that there ought to be some kind of useful support for them, while the standard leaves user agent support as a "may." That's a long way from the stated justification for the feature.There is no requirement for it in the HTML standard. >> No, they checked it in because it had gotten an obscene amount of code review and looked like a safe patch. << All of which is time spent on a new feature rather than on fixing the bugs in existing features. And what do you know, it turned out it wasn't a safe patch after all, even after all that "obscene" (your word) resource drain. That's why after a certain point you just don't let new features in, barring some drop-dead requirement. They create new problems, and evaluating them take resources away from bug fixing. Really, guys, this is technical project management 101 here. It's not some weird thing I just came up with. >> As things stand, there's absolutely no need for NS people to be "evaluating it and making determinations about it" << Funny, you just cited several ways in which they were doing just that. There's a palpable resource drain. Just reading through the related bugs shows how much effort has gone in so far. Reading the spec makes it blatantly clear that trying to determine what is "required" by the HTML spec based on the RFC keyword MUST can only lead to disaster. There is no requirement whatsoever that user agents support traversal of anchors! It is obvious that that reference was slapped on as an afterthought, because someone thought it would give a standards-like dignity to HTML 4. For better or worse, we're on our own in choosing what other features of HTML 4 are the most important to support. Given that the "opinion piece" represents the opinion of members of the W3C WAI WG as to important accessibility problems to be fixed in UAs, I'd say that's a fairly good indication that this should be considered important. While you may not believe it, I do agree that we shouldn't be throwing features into the tree willy-nilly, even some I'd love to see implemented. On the other hand, I think that we need both distinctive features and polish to succeed as a browser, and we're lacking in both right now. I think that if we feature freeze now, we won't have enough nifty gimmicks to distinguish ourselves in a comparison with IE; while we have to be polished, it does us no good to be "just another browser". As for reviews, I see an informal review by Ben Goodger 2000-10-11, another informal by blake 2000-11-01 (before he became NS), [complete rewrite happens here, including benchmarking], review by Gerv (also non-NS) 2001-06-30, review by Fabian (non-NS) 2001-08-01, [more fixes from Gerv], review by Fabian 2001-09-07, review by bz 2001-09-08, review by Fabian 2001-09-10, review by bz 2001-09-11,review by bz 2001-09-29, super-review by Hewitt (NS) 2001-10-02, and checked in. r= and sr= since the initial checkin have been trivial, 2-mins-to-review polish patches, with the exception of autohide (which is also a small patch, but obviously required more serious examination). In short, the facts do not support your assertion that there was a "palpable resource drain" on Netscape coders. As for the fact that independent contributors have chosen to spend time reviewing and working on this bug rather than fixing polish bugs, that's open source. Deal. "Netscape people manage the source, and they let this checkin happen during feature freeze" strauss, you've been critiquing this project for sufficient time to have at least accidentally picked up some information about how it works. Netscape people do not manage the source. mozilla.org manages the source. mozilla.org is not Netscape. Some (about half) of the people that coordinate this project (staff@mozilla.org) are paid by Netscape but in no way does Netscape "manage the source". You're just flat wrong on this. Your're also wrong when you claim that there was a feature freeze. There was a Milestone code freeze. This freeze is not a "feature freeze" it's a "code freeze" during which we only approve fixes that are of high value to the Milestone. This feature landed _BEFORE_ the freeze on 10/2. You're just plain wrong again. But you couldn't stop. You were on a roll with incorrect statements like "a bunch of Netscape people spending a ton of time". There were no "bunch of Netscape people". One Netscape developer who had an interest in the development of this feature spent some time helping the developers of this feature work out fixes for it. In reality the "bunch of people" during the last few days were non-Netscape developers helping Netscape developers fix other bugs that are important to the Milestone. This software project has had many stable releases. See ActiveState's Komodo, Netscape 6.1(more stable than 4.x), Bloomburg client, Galeon, and a lot more. You don't follow the process or projects close enough to make all these claims and even if you did you've made your bias and hopes for Mozilla failure well enough known that I wouldn't trust your claims even if you were better informed. --Asa Asa, I think you deserve to have a "let's set the record straight" story on the front page of mozillazine... scratch that, cnn.com :) It seems to take an inordinate of time holding down the FUD around here. ;-P ...is a perfectly stable release. I've had many more crashes with ie 4/5/5.5 than NS6.1, quit trolling. Furthermore, you assert that all this Netscape emplyee time is being wasted on the Tab feature, therefore it is upon you to proove that, as Asa provided evidence that shows otherwise. Characterizing Netscape 6.1 as "perfectly stable" is, at best, disingenuous. In my usage it appears to be more stable than Netscape 4.x and possibly more so than IE5.5, but it still crashes FAR too often - still several times a day for me. Better than the several times an hour that NS4.x and IE4/5 do, and maybe roughly where IE5.5 is or possibly a bit better. The problem is that NS4.x and IE4 are notoriously unstable products. Even IE5 isn't very good on that point. NS6.1 is useable, but its stability can only be described as "aggravating." I suppose it's better than the others mentioned (which would be "infuriating") but it's still not a wonderful recommendation. --Bruce I'm guessing that you have other problems causing your crashes. I get at most 1 crash per day, using some pretty unstable things, in my current Mozilla build (2001100403), while IE6 brings down my 98 SE system every 15-20 minutes, when I'm doing non-IE related stuff (like copying files from the desktop)! The latter is what I mean by "unstable," the former by "stable." [Of course, IE6 is rather stable in XP, but they're peddling it to non-XP users, so it should be stable in 98SE] I see from the current roadmap that the previous feature freeze has been taken back. http://www.mozilla.org/roadmap.html : "The previous roadmap charted Mozilla's path through the release of Netscape 6 and beyond, toward the goal of releasing a Mozilla 1.0 milestone. In that update, I wrote 'Mozilla needs performance, stability, and correctness' and not any particular new feature. I want to make clear here that useful and relevant (defined by the community) extensions are always welcome, provided that they don't have a high opportunity cost in terms of contributors who otherwise could and would have helped hack on 1.0." This retraction of the freeze is very unfortunate for the future of the project. Netscape people and mozilla.org people (I really don't make the distinction, you're right, because there isn't one -- Mozilla.org exists because Netscape has poured a lot of money into it, and it is accountable to it -- the illusion of the independent nonprofit is a peculiar Netscape delusion that also exists w.r.t. the Open Directory Project) have spent a lot of time dealing with this and the tab feature. That's obvious from reading the bug reports and from looking at the review logs posted earlier. You can deny it all you like, but the fact is obvious from the documentation. Mozilla has never had a stable release. And at this rate, it never will. Frankly, I can hardly believe I'm having to argue basic issues like the need for a feature freeze during beta. I have this totally beautiful image of Lee here standing in a room with people using Netscape 6.5 screaming 'But don't you know they never had a feature freeze? Even though it doesn't crash, can't you see it's unstable? How can't you see that there are more bugs reported now than when it didn't even display webpages? Why aren't you listening to me? Why, why, why?!?!?!?'... It's quite amusing really... I've certainly been aware of some large software products by major vendors which had significant features added during the beta period though this tends to be early in the cycle or to be relatively minor feature additions if it's late in the cycle. In any event, you do need to have some point where you can fix problems that exist in new features or in interactions between features without having to deal with problems introduced in new code (other than the code to fix the problems). Note that ANY new code can generate new errors -- including code that just attempts to fix another error (why do you think fixes are sometimes backed out of the tree?). Some of this is already being done during milestone freezes, more during the more extended branches and freezes for Netscape releases. The problem is that there are still an awful lot of bugs in bugzilla that really are significant errors: For example, there's currently over 80 (!) bugs in bugzilla that are reported to be crashes and that are targetted to be fixed before 1.0, and that doesn't even include any that aren't targetted for releases past 1.0. This number has been slowly drifting upwards - a couple of months ago it was about 60. Now of course some of them are likely to be unrecognized duplicates of bugs that were already fixed, or reports that are simply incorrect (WORKSFORME) or that have always been in the product but have just been found. But these are some of the most visible types of bugs, it's really critical to make sure that they are in fact valid bugs and find some way to fix them. Granted that it's most likely impossible to find and fix them all, this trend is not good. There ought to be a greater effort to reduce this number before adding more features. Generally too it's better to get rid of as many existing, known bugs as possible before adding very much new stuff - otherwise you can very quickly get yourself into a testing and quality control nightmare. As far as the end-user experience goes, there are still a lot of crashes that I encounter in my usage pattern. I think it's significantly fewer than NS4 at this point, possibly even fewer than IE5.5. (For some reason my usage patterns seem to exercise browser bugs ... lots of people seem to think IE5 is a pretty stable browser but I find it crashes with disturbing frequency). I really DON'T feel I have a completely adequate browser at this point from either Microsoft or Netscape - both of them are buggier than a roach motel. But that's a whole other topic; and I don't think you'll win a lot of new users by just having DIFFERENT crashes than IE (!!). And this is just the crashers ... there are lots of "significant" bugs that don't actually "crash." That doesn't mean that those can be ignored, though they may often be less visible than crashers. To end on a lighter note, one of my favorite expressions I've heard about adding things to softare products is "New and better FEATURES for new and better BUGS!" But it's not just an amusing comment, it's actually a telling comment about software development. --Bruce I think you're making a very valid (though nearly religious) point about how projects *do* need an occasional freeze on new code, so that developers can concentrate on fixing the code that's there. In an ideal world, you have a staff of developers that you can simply re-task and allocate to fixing problems. A feature freeze in this type of environment allows you to move those developers working on new features to the job of fixing the bugs in a product. The problem is, this isn't really how OpenSource works. With an army of moderately-skilled in-their-spare-time developers, you can't just say, "I want all of you to start working on bugs X, Y and Z." 90% of them aren't remotely qualified to do that. The 10% that are left might oblige, but others might find it boring, so they won't participate. This is OpenSource. In situations like this, if you have a large number of 3rd-party developers working with a large project, you have these developers finding something that interests them, and then coding in response to that interest. Forbid them to develop this interest further (since it's not a bug), and they will either stop contributing, or they will continue working on the side. After all, we're doing all of this in CVS. You can have multiple trees of development going on simultaneously. This is OpenSource. So basically, lighten up. Mozilla is getting some great stuff accomplished using this development model. Their accomplishments might not be in the area of bug fixes, but Mozilla is improving nonetheless. As another poster mentioned, "Deal." If you want to fix bugs, you know how to do contribute. Dictate development priorities to developers you pay, not the ones that are volunteering in their areas of interest. I would much rather have a paid Netscape developer spend some of his time trying to integrate a very useful feature that implements a piece of HTML functionality than have him defer a contribution like this indefinitely. I really don't understand why this is getting so blown up. (I notice everyone is still ignoring Bruce Wright. Too reasonable?) If what you say is true -- and it seems like a reasonable analysis of open source social dynamics -- then what you're saying is that open source projects can never stabilize. Fortunately, I don't think that's true. We can see a counterexample, the Linux kernel. Interestingly enough, the kernel is much more conservatively managed than Mozilla, and does lock out new features as releases are approaching. There are plenty of branches and conditionals but new things are locked out of the main trunk and default build during stability pushes. The kernel also has a much smaller number of contributors. Mozilla with its promiscuous style of management has not been able to achieve the same stability. So I think it is not so much that this problem is inherent to open source, but to a particular open source management style. What makes it a problem is that without lockdown during stability pushes, a large software system can't stabilize. In this respect, I think Mozilla could learn a lot from the kernel group. #199 Re: Re: Re: Re: Re: Re: Re: Re: Re: Cool, but ...by Fastolfe Thursday October 11th, 2001 5:25 PM I agree with what you're saying here. It is the style, but I don't think that OpenSource projects *can't* stabilize. You have to have *some* sort of steering in a large project, or you're right, they won't. How much steering and the strictness of that steering determines how a project will develop, and the Linux kernel has some excellent steering, if you ask me. I completely agree. Mozilla is less-strict about their steering, but that doesn't mean it's absent altogether. Somebody decided this was worthy of being integrated in the main Mozilla source tree. This is a policy decision that really shouldn't be debated here. Personally, this is a relatively small but significant feature that further distinguishes Mozilla as a platform that not only sticks to standards, but embraces the spirit of those standards. I think an occasional addition like this is worth it. But that's just my opinion... Any enhancement is going to have the chance of introducing bugs, almost by definition. It doesn't matter whether it's been developed by inside or outside contributors or how long it's been in development; often defects don't show up until something is in widespread use. Any time you're adding things to a program, you run the risk of adding errors. Testing them and tracking and fixing the errors takes time away from working on testing and fixing other errors. I really don't think that this is a point that can be disputed by anyone who has ever been seriously involved in software development. Now in this particular case, the potential liability may well be outweighed by the potential benefits; it may have been tested well enough and have a high enough payoff. But that's not the point - the point is that the general tendency has too often been towards adding "features" rather than fixing "errors," and as far as that goes Strauss is right on the money. I have had some disputes with him about how the bug counts should be interpreted - I'm afraid that he's often too simplistic about them - but if you don't call a halt to "features" at some point and work on fixing things that are broken, you will never reach closure on a solid product. And in the end, isn't that what everyone wants? --Bruce I agree with you 90% here, but in this case i applaud the recent addition's of Tab's and the Link toolbar. Both of these offer significant enhancement to the end user. I think that Mozilla really needs this kind of attention to detail to win over a vastly apathetic public. Netscape 6.5 might be our last biggest chance to win back a lot of people who are kinda wavering on their browser choice but who were really turned off by 6.0 ... the fact is that saying "Come download 10 megs of the same browser that you tried before but this time we really really promise it will be stable" isn't gonna work :) We need obvious new features that will make people go WOW again. Is there a list anywhere of all of the cool things that can be turned on in the prefs.js file? I have build 2001100403, and I see no view -> show/hide -> link toolbar option. I even tried a new profile to no avail. It has been disabled. See bug http://bugzilla.mozilla.org/show_bug.cgi?id=103082 If you want to see it in action, download an earlier build from the previous day. By 2001-10-04 01:43, it was backed out due to the large performance impact it was having (bug 103082). Looks like you'll have to grab a 2001-10-03 build to see it in action, for now. Bizarre. No wonder the bug line never sinks. Is anybody managing this effort? If the feature had been constructed by core Mozilla developers, that question would matter. But since the developers of this patch (and it has been in the works for over two *years*) are, for the most part, new Mozilla contributors (or at least were when they started on the feature), it doesn't matter. The feature has been reviewed numerous times, and except for a performance impact that is being fixed post haste, it's ready for prime time. If Moz/Netscape is ever to win back market share from IE, its needs "Killer Features". These are things that, once someone tries them, they wonder how they got ever got along without them. Many of these checkins that you are disparaging are implementing Functionality that many web designers/Internet developers consider "Killer Features". When web developers are testing/developing their creations on Moz/Netscape because of this, this is good for Moz/Netscape. I certainly find many of these new features helpful. >> I certainly find many of these new features helpful. << I do too, as an end user. They're good features. What I'm talking about is their logistical impact on the project. No software project of medium or large size can achieve a stable release without eventually declaring a moratorium on cool new ideas and just stabilizing what's already done. This is often very emotional and there are many engineers who just won't accept that the time for latest-cool-idea-of-the-week isn't now. I've lost friends over feature freezes. But I'd rather have lost friends than failed to ship the products. "No software project of medium or large size can achieve a stable release without eventually declaring a moratorium on cool new ideas and just stabilizing what's already done." I agree. Isn't that what they did with Mozilla .9.2? Didn't it (temporarily) work? (Please correct me if I'm mistaken.) - Minh Strauss, isn't that axe sharp YET? >> No software project of medium or large size can achieve a stable release without eventually declaring a moratorium on cool new ideas and just stabilizing what's already done. << It's true that this statement reflects good project management in general, but let's face it: what you're really saying is "(Mozilla can't) achieve a stable release without eventually declaring a moratorium on cool new ideas and just stabilizing what's already done (and it has not done so)," and this simply isn't true. For one thing there have been numerous freezes made while stabilization takes place; do you even have a clue what the milestones were FOR? Did you suppose they were just a publicity stunt? More damning to your claims is the fact that Mozilla has, in fact, released a lot of stable code. Third parties have released stable browsers based on Mozilla code. Public forums and news outlets have proclaimed that It Was So. I'm not sure what "Mozilla" your complaints address, but it doesn't seem to be the one that this site reports on. Lastly, I would suggest that your suggestion that Mozilla be managed exactly like any other major software project is narroe-minded and short-sighted. Traditional commercial software houses are focused on sporadic, closed-source releases, while any incremental improvements are usually unscheduled and released only as bug patches. By contrast, Mozilla doesn't seem to have any specific stopping point; even the push for 1.0 seems to be more symbolic than anything. It doesn't make sense to have Mozilla completely stop for weeks or months at a time, during which many of its developers are simply told "sorry, you can write it, but we're not interested until Christmas, and that's all there is to it." Please, go off and cut down some trees now. I think we've all heard enough. >> Third parties have released stable browsers based on Mozilla code. Public forums and news outlets have proclaimed that It Was So. << That's just not true. All the Netscape 6.x releases have been awful in terms of bugs and performance, and their bugginess has been noted in the press in every review I've seen. At best, lately we have been getting some remarks that's it's improved from previous versions (which it has), but not that it is actually good. The instability of Netscape 6.x is well known both in the web developer community and among those end users who are aware of its existence at all. That's why less than 1% of web surfers have adopted it, even though it's been freely available for so long -- because of its well-deserved bad reputation for bugs and bloat. Again, you may not like what I am saying, and I may not be doing anything to sugar-coat it for you, but it's not something I just made up. You really ought to know this already. If you don't, you should thank me for telling you. With respect to Linux Mozilla packages, I'm not too concerned if they've gotten a positive response. Every single time I have been told by Linux users that a program was wonderful (GIMP, cvs, etc.) and I've gone through the multi-page setup instructions and tried it out, I've found it to be far below the standards of professional software. Linux users have very low critical standards and seem to be happy to get anything that just sort of works, as long as it's free. That's why Linux on the desktop has less than 1% of the non-technical end user installed base. As for your penultimate paragraph, I appreciate your thoughts and the clarity with which you express them, but I think you're ignoring some basic facts about software projects. The reason that feature freeze is necessary to attain stability is not because of release schedules. It's because of the complexity issues in software systems. New features create new problems. As long as you are introducing features, you will be introducing problems. Because features interact with each other, the introduction of new features creates a multiplicative rather than an additive set of new problems -- that is, as the system size increases, the potential for problems with new features also increases, because they interact with more other features. To attain stability, you must reduce problems, not increase them. To reduce problems, you must hold the system size nearly steady. That's as true of incrementally released open source projects as it is of commercial software. If you don't want to hear from me any more, I suggest you discuss the issue with Bruce instead. His simple, rational post seems to have been all but ignored in all this. If you get a good conversation going there, I'll gladly bow out. #117 Re: Re: Re: Re: Re: Cascading Bookmarks Possible?by SmileyBen Saturday October 6th, 2001 1:28 PM Oh Lee... Lee, Lee, Lee, Lee, Lee... I find it strange that you explain how much users hate Netscape 6.1, when it currently has the highest rating of any browser on download.com... I guess it\'s all the minor bugs opposite lack of major ones that you hate... God damn those requests for enhancements - I always find it annoying when you have a happy, stable browser, but people have said they want additional things from it. It always impinges so much on the browsing experience... So yes, Lee, you seem to be flying in your negative imagination land. Oh, Lee, how much we wish you could be happier with the world. #120 Re: Re: Re: Re: Re: Re: Cascading Bookmarks Possibby strauss Saturday October 6th, 2001 1:52 PM You can't really think that ratings on download.com have anything to do with anything, can you? I mean, you're just teasing me, right? They're not comparative rankings. Anyway, it's not even true. Compare the MacOS Netscape 6.1 http://download.cnet.com/downloads/0-10201-100-6818222.html?tag=st.dl.10000-103-1.lst-7-1.6818222 with the MacOS Internet Explorer http://download.cnet.com/downloads/0-10201-100-1591065.html?tag=st.dl.10005-103-1.lst-7-1.1591065 . Last time I looked, 81% was higher than 55%. You might also look at the download totals and vote counts. Here's another link for you. Enjoy! http://www.TheCounter.com/stats/2001/September/browser.php #122 Re: Re: Re: Re: Re: Re: Re: Cascading Bookmarks Poby SmileyBen Saturday October 6th, 2001 3:03 PM Fair enough about Macs, but I thought minority operating systems don't count. Interesting that nobody on the counter appears to be using IE6. Interesting also that suddenly when you're talking about user preferences you suddenly change your mind and talk about adoption numbers. It is indeed strange, bizarre, almost to the point of twilight-zoneness, that the majority of people appear to use the browser that came with their operating system. And on Windows, yes, Netscape 6.1 is in the lead on download.com. Nope, I don't think that's authorative, but many think of it as the most usery of user preference ratings, and considering many comments talk about 6.1 wiping the floor with IE (and some of course the other way round), I think it's at least of interest, Lee. This is standards compliance, not some whizbang feature. Support for the LINK element has been part of the HTML standards since HTML 2, but until now most browser developers have been too apathetic about it to implement it. someone should acutally look more on the project itself than on some buglines or the like. Then someone could see, that this product is simply cool, works really good and has features that matter all with very nice standard compilance and even nice design. I'm happy with this browser (just to say something positive which every of the developers deserve by giving me my favourite browser ;) This is TOtally Off Topic.. But you have got to try this. A new project has opened at Mozdev called OptiMoz http://optimoz.mozdev.org/ Basically it allows GESTURES in Mozilla to do simple tasks like Back, Forward, New Window, Show source, etc. I tested it out with Yesturdays Build, and it ROCKS.. This is definitally something I wand installed permenantly in my Moz!!! Hope you enjoy Cheers --Jed Optimoz: a.k.a. MozGest http://optimoz.mozdev.org/ Brilliant! Now all it needs is a proper download manager and the modern chrome conforming to my system colours and I can get rid of Opera! :-) "Brilliant! Now all it needs is a proper download manager and the modern chrome conforming to my system colours and I can get rid of Opera! :-)" Can't help with the chrome, but take a look at this http://bugzilla.mozilla.org/show_bug.cgi?id=102477, this http://www.silverstone.net.nz/work/DownloadManager.htm and this http://mozilla.org/xpapps/MachVPlan/Download_Mgr_estimate.html for the download manager. Alex " modern chrome conforming to my system colours " Just use classic. It's not like classic is any uglier than Opera and it respects system colors and fonts. --Asa With the tabs and now the "gestures," it seems like people are trying to make Mozilla emulate Opera. Not only that, but appears to work on the 0.9.4 branch! cool. Why isn't this in the trunk? Joseph Elwell. i was referring to mozgestures, not the links toolbar - which is already (on again/off again) in the trunk. Joseph Elwell. - to bad mozillazine doesn't understand newlines. We can't put everything in the trunk immediately, or... 1. We'd never release a "ready" browser as long as people had Ideas. 2. We need cool add-ons like this to be the basis for Mozilla add-ons in the future. I would like a browser with support for HTML2 (LINK) and then download a whole bunch of cool add-ons (Gestures, etc.) So *I* choose the performance hit, and I can pick and choose which I like. And besides, we can't have a browser with this incredible potential for expandibility and have all potential expandability integrated into it. There'd be no reason for XPI install! :-) As I was looking through the bug list, I came across something I had not seen before: mention of a rel="icon" attribute for the LINK tag. It's not part of the standard, but I haven't been able to find any documentation on it. What is this attrbute value for, and how is it used? It looks like some kind of analog to IE's favicon.ico, but more flexible (not to mention that it doesn't hit Web servers needlessly whenever the page is loaded). Am I correct in this? That's exactly what it's for. http://bugzilla.mozilla.org/show_bug.cgi?id=32087 It's basically MS's favicon feature with 2 important improvements: 1) It's optional for the user, so somebody who doesn't want servers to be able to track which pages he/she has bookmarked can turn it off. 2) The server can specify where the icon file is, or if there isn't one. So servers don't get bombarded by requests for a nonexistent "favicon.ico" file. Does mozilla do something with the "<link rel=icon"? Does it use the image for the bookmark or something? We were able to specify the location of the icons in the Internet Explorer version. I think it would be good if Mozilla looked for favicon.ico too so it would download icons for all of the pages designed for Internet Explorer. If any people are actually afraid of websites knowing the pages have been bookmarked then the problem can be solved by making it possible to disable the search for favicon.ico. Before discussing this, read the bugs on it, where it's conclusively proved that favicon is a badly-designed feature and there are much better options. :-) Gerv Not to be critical or skeptical, but who uses link tags for anything other than stylesheets? I'm sure that if this was a widely implemented tag, this toolbar would be really useful. For the moment, I'd say please don't turn it on by default. Most people won't know what to do with it. bugzilla for one. it will autopopup when you are looking at a page that uses link tags, so it shouldn't be a problem. Features are only implemented by web developers only after they are available in browsers. Do you think a developer would have added a <center> tag before Netscape included it in the browser? While I suppose that's true, my main point was that it shouldn't show up by default, as it unfortunately did when I started up Wednesday's build and found the toolbar active, but all buttons disabled (because I was on a page that didn't use link). If every web browser waited for a standard to be widely implemented before supporting it, we'd still be at HTML 1.0 or something, because no developer is going to implement code that no browser supports. The chicken came first because someone had to sit on the egg. "The chicken came first because someone had to sit on the egg." Actually, something that was "not-quite-a-chicken" laid an egg that contained a mutant. That mutant is what we today call a chicken. It was a "not-quite-a-chicken" that sat on the first chicken egg! The chicken was first because animal species are defined by their adult state anatomy and physiology.(Plant and microorganims species are a different concept) Chickens are birds with such and such qualities, among them, they reproduce by laying eggs. The definition is NOT the other way around, that chicken came from eggs. For this reason, in Biology, this has never being a scientific dilemma, The chicken, by definition, must have been first. Interestingly enough almost all religions agree with this statement too... God created all animals and plants, etc etc. They never say that God created eggs from where chicken hatched. ;-) The chicken was first because animal species are defined by their adult state anatomy and physiology.(Plant and microorganims species are a different concept) Chickens are birds with such and such qualities, among them, they reproduce by laying eggs. The definition is NOT the other way around, that chicken came from eggs. For this reason, in Biology, this has never being a scientific dilemma, The chicken, by definition, must have been first. Interestingly enough almost all religions agree with this statement too... God created all animals and plants, etc etc. They never say that God created eggs from where chicken hatched. ;-) well i have worded my critisism about people doing all kinds of things instead of what I want ;) above ... But this IS a nice feature - incidently I have had those link tags in my homepage and other pages I designed for a while already (just in case search engines would use it). One nice thing you can put there is a link for alternate language versions. It is very nice to have those show up in Mozilla"s new toolbar! > Not to be critical or skeptical, but who uses link > tags for anything other than stylesheets? I will. In fact I just put LINK tags on my first site today, just to see how it would look in Mozilla. It wasn't that big an effort, so I'll probably put it on some more sites soon. I was going to start adding them to my pages too, but it seems the Links bar is turned off in my build (2001100514). Nothing happens on any of the sites that already have Links. My Links toolbar is all greyed-out. Unfortunately. I\'d really like to get going on this. Where can I get info on the current turned on status of Links bar in the builds? I browsed through the various bugs, but I didn\'t get any wiser. A lot of tools for converting documentation from other formats to html create them automatically, so it should be useful even today for the kind of people who also used the net before September. Its great to see so many people think this is so cool. I gave the toolbar the kick-in-the-pants it needed after picking up work by Tim Larson from bug 2800 by making a package here: http://segment7.net/mozilla/linktoolbar/index.html From there Tim Taylor picked it up and gave it a huge tweaking, and along with Gerv the toolbar was polished into submittability. Now I'll have to find another poor, neglected bug to give a kick-in-the-pants to ;) Fancy tackling print preview? http://bugzilla.mozilla.org/show_bug.cgi?id=20943 Alex Does anyone know if there's been any planning (beyond what you can find in the bug reports) with regard to adding support for the CSS2 paged media properties (like page-break-before) after Moz 1.0? Proper support of those would be killer. Seems like the link toolbar (or now known as the "Site Navigation Bar" http://bugzilla.mozilla.org/show_bug.cgi?id=102991 ) will not support frames http://bugzilla.mozilla.org/show_bug.cgi?id=103204 because as Gerv puts it "Frames suck." Interestingly the HTML4 spec http://www.w3.org/TR/html4/struct/links.html#h-12.3 allows "target" as an attribute of <link>. And it also allows intrinsic events too! I'm guessing that moz wouldn't support these anytime soon (if ever). As much as I agree that frames suck, the attitude not to support stuff that sucks sucks too. I dont like to use a browser that wont let me view my favorite websites with the same easy as other browser do, just because some people dont like the way that website was programmed. I am talking of the back button issue here: IE knows how to do it so eventually somebody should be able to make it work in mozilla too. I just HATE to be unable to go back at random points within a framed website and it is one of the major annoyances that still exist with mozilla. As it currently works, it would be hideously ugly in frames; the toolbar isn't really designed to be cloned all over the place. However, frames support might fall naturally out of some changes being made; read the various dependencies of bug 103053 for the details. How can you compare our back button brokenness with not supporting frames for <link>? That's a credibility-killer. :-) Gerv Why is mozilla wasting time on a "feature" that the w3c site hardly utilizes and 99% of sites wont use for a while. Give us features that we can use like a print preview, more drag and drop capability and less ram usage. Mozilla uses more ram than my PHOTOSHOP, whats up with that!!! What do you think people, am I crazy?? Great job so far, mozilla is my defualt browser. somebody else has answered a similar but less negative rant of myself above with the explanation that this is just one of the many features that have been contributed by non-netscape people. this is nice, this is fine, but i still think that mozilla is a product that has too many cool features and not enough boring, down-to-the-basics, everyday-work supporting features. that means that mozilla will be loved and used by a minority and the majority of boring business users will just stick with browser that do what they need even if they would love to have an alternative. maybe that sounds a bit harsh, but I do see quite some small, boring but important things not get touched for months or even years now while one cool feature after the next is landing. i do believe that the most important species of users is corporate users that do not have a background in hacking or informatics, but routinela and extensively use programs like web browsers and messengers in their day to day work. > not enough boring, down-to-the-basics, everyday-work supporting features. If they matter to you, and you are volunteering to write them, that would be great. Whatever they are. In the mean time, I\\\'m going to keep having a ball. :-) Gerv well, but thats exactly what i am trying to say: mozilla looks a bit like a web browser for programmers, and programmers will happily add features *they* want. I am not a programmer and many browser users arent either. they are unable to add what they would like to have and some, very few of them, will complain or ask for features. the bottom line probably is that I would love to have those programmers also listen a bit to boring requests and maybe rething priorities so that mozilla will have a chance outside a small community of fans. i am a fan, i would love mozilla to kick ie's ass, but i wont be able to learn programming fast enough to do it myself :) I think it would be interesting to have a poll on this website that asks something along the line of "Do you use the Links toolbar?", just to resolve all the arguments over whether or not the Links toolbar is useful or not. >> I think it would be interesting to have a poll on this website that asks something along the line of "Do you use the Links toolbar?", just to resolve all the arguments over whether or not the Links toolbar is useful or not. << Is there someone who said it wasn't useful? That's not the issue. The issue is that to stabilize a system, you have to stop adding features at some point. You've rather missed the entire point. It may not be totally useful now (this is why we have auto-show) but it will be far more so in the future. No-one will use <link> unless browsers have UI for it. The <link> concept is excellent (logical connections between documents), and also a great accessibility aid. Gerv I work for a big US multi-national(which I can't name) that has been seriously considering deploying Mozilla or eMojo for a while now. The situation at present is that we cannot deploy either products because of several issues, including the following: * RAM usage The magic number is < 20-25 meg at any time, regardless of how many/what type of windows are open. Forget price of RAM etc. Corporate deployment is like a glacier and noone will sanction a RAM upgrade deployment just to use another browser. * NTLM Challenge/Response support There is an open bug for this that suggests a solution is practically ready but seems to have stalled at the final fence. * Browser only package Outlook is used and is popular, so the browser should not load unnecessary libraries relating to mail client. I know theres a browser only install, but I'm not clear if it has all the non-navigator code stripped out. * Integration with Outlook as the mail client Not sure if this is already there. Need mailto: links to fire up Outlook only. * ActiveX control support Not sure if Adam Locke's control/plugin allows this. It does in NS4. * Ability to persist alternative link style choices minor issue as it could be done with a cookie probably. The fact that Mozilla can do it in the first place is a selling point. * SVG support -(wish list) Again, not sure if this is imminent. It used to work with Adobe's plugin but nowe it doesn't. I know there is a project close to landing a solution. On the plus side, the new MDI tab bar is generating the WOW factor. if it was possible to remember the tabs you had open between browser sessions, or to open browser with preset default tabs, then this would be a MAJOR selling point. We actually have a project designing a bolt on control to allow IE to do this. But I tell you something now. If you wanna make corporates take note - get NTLM authentication working. It is a major factor in IE's success on the corporate desktop. We have advocates of a deployment, but practicality dictates and the above points are seen as crucial. I believe NS has some sort of "enterprise" team which helps identify bugs necessary for corporate adoption; Asa probably knows how to contact them, as I'm sure they're interested in this kind of input. I know one of the problems with NTLM is that it's poorly documented, and Microsoft's own implementation does not always jibe with the documentation that does exist. If bug 23769 is the bug you're talking about, it's been marked enterprise- very recently; making some noise about that might get that reversed, though. Using external email clients ultimately depends on getting IPC into Mozilla, bug 68702, which seems to have stalled recently from lack of testability on Mac OS X. [I'll spare you the obligatory "why would you guys want to use the virus-writers' mail client of choice spiel] I don't know exactly what libraries get loaded in the mailnews disabled version, but there's been a lot of unnecessary dependency removal recently, so that situation should be in good shape. I'm almost certainly alternative style choices can be persisted. This could be done via a cookie + dynamic construction of the <link> elements; read the cookie for the title of the preferred stylesheet, and set the link with that title to rel="stylesheet", setting all others to rel="alternate stylesheet". In fact, I'm pretty sure I've seen it implemented already, but I can't remember where. Don't depend on the internal SVG support for extensive use of SVG right now; getting it to work properly will require some rearrangement of the architecture which I can't imagine happening pre-1.0, and it isn't compiled by default in the builds being distributed. I see an SVG plugin crash on Mac OS X in bug 98082, but nothing about it "not working"; if it isn't working, please file a bug on it, someone needs to know. Again, I'd strongly suggest getting in touch with the team evaluating features for enterprise to discuss the importance of NTLM. "I work for a big US multi-national(which I can't name) that has been seriously considering deploying Mozilla or eMojo for a while now." I thought eMojo wasn't out yet. And why can't you name your "big US multi-national"? Alex >I thought eMojo wasn't out yet. Neither is Mozilla. Doesn't stop people looking at it based on the current state of play >And why can't you name your "big US multi-national"? This is a "political" issue for the company and I could get sacked if I mentioned their name without clearing it first. #137 Re: Re: Re: A Sane wish list for a corporate uptakeby AlexBishop Sunday October 7th, 2001 9:41 AM >>I thought eMojo wasn't out yet. > Neither is Mozilla. Doesn't stop people looking at it based on the > current state of play Yes, but you can go and download Mozilla builds and take a look. The best you can do for eMojo is to take a look at 0.9.4. Anyway, I hear that eMojo is coming out in a few days, so it won't be an issue then. >> And why can't you name your "big US multi-national"? >This is a "political" issue for the company and I could get sacked >if I mentioned their name without clearing it first. Awww... can't you even tell us which industry it's in? :-) Alex > Yes, but you can go and download Mozilla builds and take a look. The best you can do for eMojo is to take a look at 0.9.4. Anyway, I hear that eMojo is coming out in a few days, so it won't be an issue then. Which is what I've been doing for last weeks. I say Mozilla/eMojo since the suits seem more comfortable with Netscape as we are a Gold customer or whatever its called these days. Its all Mozilla to me so I don't really care. Saves having to strip out AIM etc...
\\\"The situation at present is that we cannot deploy either products because of several issues, including the following:\\\" Then when explaining the various issues, you seemed rather uncertain about whether Mozilla actually had problems with those issues or not. Since those issues are not of real concern to ME, I have no immediate knowledge about their status. However, if I were interested then I am sure that I could quickly determine whether or not ActiveX plugin works and whether or not the browser only installation loads unneeded libraries. Of course if I were I a large mutli-national company interested in possibly using Mozilla, then I might contact someone like Mitchell Baker about my needs. I know she works with companies developing projects based on Mozilla, but if you are only talking about deploying it as your company browser of choice then I am not sure if she handles that kind of thing or not. If you are talking about using Mozilla as a basis for some project for which you need the various features that you mentioned, then I would suggest your company assign one of their programmers to the tasks of addressing the appropriate bugs. > ... but if you are only talking about deploying it as your company browser of choice then I am not sure if she handles that kind of thing or not. This is just about using Mozilla as the company browser. We used to have NS4 and IE5 on the desktop. We are now IE only. At the time (6 months ago) The decision to drop NS4 was made, Mozilla was looked at but rejected on the grounds I mentioned, plus a few more that have since been resolved. The decision is not mine to make anyway. I am just one of several people pushing for a standards-based approach to web development within the company so we don't get locked into proprietary IE code. The recent NIMDA virus hit very hard as well, so the idea of having a second browser is gaining ground. Mozilla would be a second browser that also happens to be very standards compliant. >Then when explaining the various issues, you seemed rather uncertain about whether Mozilla actually had problems with those issues or not. As I said, these points were plucked off a longer list of blockers written 6 months or so ago. I just skimmed through and grabbed the ones of which I have some knowledge. I am pursuing clarity on all the points I feel are relevant. This post was just me thinking aloud... >Since those issues are not of real concern to ME, I have no immediate knowledge about their status. However, if I were interested then I am sure that I could quickly determine whether or not ActiveX plugin works and whether or not the browser only installation loads unneeded libraries. I have made a few enquiries about ActiveX support. I would just add that the list I gave had about 5 points on it. The original list had about 30 issues listed on it, so I'm getting there. >If you are talking about using Mozilla as a basis for some project for which you need the various features that you mentioned, then I would suggest your company assign one of their programmers to the tasks of addressing the appropriate bugs. Again this is in the context of deploying Mozilla as a desktop browser to sit side by side with IE. IE does all the things needed of it, so the chances of developers being assigned to work on Mozilla are zero at the moment. The current economic climate does not help either as all non essential projects are on hold/cancelled. I follow a few bugs in Mozilla but not all of them and I am also learning XUL so I can get involved. Cool. Just visited Adam Lock'es site and tried out the Mozilla plugin. It does indeed allow Mozilla to run pages containing ActiveX controls, albeit with a few minor restrictions. This may sound a little harsh, but why should Mozilla contributors care what your needs are if you've already made it clear your company won't assign developers or make a contribution? Business is all about "you do something for me and I'll do something for you", not "you do something for me and I'll make more demands". TonyG's company is something called a customer. You know what I mean? Mozilla doesn't really have customers (i.e. no one is paying mozilla.org for the software). If he is really interested he should be telling whichever mozilla contributer he is getting the software from. >Mozilla doesn't really have customers (i.e. no one is paying mozilla.org for the software) A user is a customer is a user is a consumer of Mozilla. Same thing, whether or not money is involved. The point is that it is wrong to say you are allowed an opinion unless you contribute. My company as an entity does not contribute, although I contribute personally through Bug reporting and through that other listed component of Evangelism, so I am entitled to an opinion - if indeed participation is some sort of entry qualification. >If he is really interested he should be telling whichever mozilla contributer he is getting the software from. I presume by "he" you mean me (TonyG). If I wasn't really interested I wouldn't be in here expressing a reasonable opinion and answering the replies. nor would I bother reporting bugs or trying to promote the software within the realms that I have some influence. >... whichever mozilla contributer he is getting the software from. Not sure what you mean here but if you mean I should be talking to the owners of bugs relevent to my issues, then thanks for the advice, I already have on a few occasions through bugzilla and moznet. Ultimately the blocker is memory consumption and I know there is no point in going to anyone as the issue is well known and actively worked upon. > Mozilla doesn't really have customers > (i.e. no one is paying mozilla.org for > the software). If he is really interested > he should be telling whichever mozilla > contributer he is getting the software from. Mozilla does have customers - Netscape is a customer, IBM is a customer, RedHat is a customer. They don't buy seats, but they donate a lot of resources to the project. Netscape has customers. If Mozilla doesn't satisfy Netscape's customers, it won't satisfy its own customer, Netscape. Given a choice between sending an email to Netscape and posting a comment here, I'd go for posting a comment here - fewer layers of bureaucracy (this isn't a comment specific to Netscape, but a general observation that the fewer stops a comment has to make before it gets to the developers the better). Of course, I'd go for posting a bug report to bugzilla above all, but his point is to highlight the bugs he thinks are important (and a vote doesn't always help much). The developer community is not Mozilla's only customer, and the product should not be designed just to answer to developers' needs. The open source model has to work differently here from the way it works for gcc, which is only used by developers. Apache might be a better model to think about: most of the servers running Apache aren't owned by companies that have contributed to Apache, but that doesn't mean that the Apache group ignores those customers' needs. (Of course, Apache isn't distributed by a large commercial company under its own brand name, but the analogy is still useful). That said, if a company is going to use Mozilla, it would only be fair to contribute what they can to the project in the way of testing, bug reporting, and if possible development. Where is the documentation of which <link> atrributes are picked up and how they they are interpretered This isn't defined in any spec; I believe Chris Hoess or someone else wrote a spec collecting fragments of information from all the relevant places. Check bug 87428 or 2800 for that, or read the code to see which ones we recognise. Gerv The link toolbar picks up the "rel" attributes of <link> elements (<link rev="made"> is also grandfathered in). Right now, we assign "home", "start", "top", and "origin" to the "top" button, "up" and "parent" to the "up" button, "begin" and "first" to the "first" button, "next" and "child" to the "next" button, "prev" and "previous" to the "prev" button, "end" and "last" to the "last" button. The "Document" and "Other" menus will probably be combined soon, so I won't go into them; suffice it to say that rel="stylesheet" and rel="icon" or "shortcut icon" are filtered, but any other values of "rel" will appear in the menu. The logic of exactly what gets mapped to what in the hierarchical buttons may change a bit once the spec in bug 103469 gets hammered out, but you should be fine if you stick with the HTML4-defined link types. (P3P*, schema, and meta will also need to be filtered, as well.) I hope that "next" and "child" will be decoupled. "next" has meaning for sequential collections, and "child" for hierarchical ones, but a page can easily belong to both kinds. For example, a site could have a hierarchical structure where sibling documents are ordered. With "next" and "child" combined, congruent sibling pages would get mixed in with child pages. Fortunately, from the draft spec recently posted, it looks like sequential and hierarchical link types will be kept separate. Can Recall (http://recall.mozdev.org/) incorporate tabbed support? Is it possible for it to memorize the state of the tabs? OFFTOPIC: A killer feature would be for Recall to be incorporated into the Mozilla trunk, and when turned on, could ask if you want to save all window states when you exit. (I am not aware of exact Recall behavior currently) And of course when previously saved will prompt to restore states at launch. I don't see why anyone wouldn't like this. Multizilla users have asked for a related feature to open a given list of urls into tabs everytime you open Multizilla Well MozillaQuest has published an article about the new Patch Maker tool by Gerv. This article still has some of the bad grammar problems of the typical articles but at least this one breaks the mould of recent articles. It might be the start of Mike Angelo starting to write constructive articles about mozilla rather than rehashing the same crap again and again. As some sites like linking to MozillaQuest lets hope so. http://www.mozillaquest.com/Mozilla_News_01/Mozilla_Patch-Maker-01_Story01.html PS if you look at some of the really old MozillaQuest articles you'll notice that he did try to be a useful member of the Mozilla community in the early days. Then for some reason he decided to continually bash Mozilla. Only he knows his true reasons for this (to get more hits, or perhaps he was genuinely disappointed that things were taking so long, etc) but lets hope this is the end of the mozilla bashing crap, or back it up with proper facts Wow. Dr Jekyll I presume... If I wanted to try and fix some bugs using Patchmaker, how would I best go about identifying them in Bugzilla? Or is it just a case of poring over them and identifying a few candidates? Be kinda cool if those that are high level fixes (possible through Patchmaker), were flagged for quick pullout. Of course, there was the obligatory dig at Mozilla if you read the article: "The impetus for creating Patch Maker seems to lie in the fact that Mozilla bugs are raging out of control." Is there a Bugzilla query that will find a list of bugs that can be fixed by use of Patch Maker ? It would be interesting to see if the number of chrome-related bugs has been "raging out of control" since Angelo doesn't provide any evidence to back this statement up (but since when did that stop him before ?). > Is there a Bugzilla query that will find a list of bugs that can be > fixed by use of Patch Maker ? I'd search for normal, minor and trivial bugs in Themes an XPApps and related components, or Mail Front End. Gerv "Well MozillaQuest has published an article about the new Patch Maker tool by Gerv. This article still has some of the bad grammar problems of the typical articles but at least this one breaks the mould of recent articles. It might be the start of Mike Angelo starting to write constructive articles about mozilla rather than rehashing the same crap again and again. As some sites like linking to MozillaQuest lets hope so." Unfortunately, not. The latest article http://www.mozillaquest.com/Mozilla_News_01/Mozilla_0-9-5_branched-01_Story01.html is entitled 'Mozilla 0.9.5 Branched -- Buggier Than Ever'. Alex I should have expected that he'd go back to his old ways. I just wish I could get rid of the addiction to his site, normally his mozilla articles just amuse me because they're so pathetic. A lot of important sites still hasn´t theur <link> tags... e.g.: mozillazine, mozilla itself and the W3C... We don't plan on adding them either. We already have all the relevant information available in the sidebar, without the need to put it in a toolbar on every page of the site. No site will rely solely on <link> tags. These tags are meant to be used *in adition* to the noermal site navigation. What they provide is a common interface to, for example, go to the home, or go to the next mozillazine news item. Why did you choose to put this news item in the front page if you think that these tags are not worth adding to MozillaZine? daily annoyances right now. I haven't see the link bar pop up even a single time yet, so it's still just an idea to me, but the following are very annoying EVERY day: 1) no way to save a page with images - and in a folder? I always have to reload a page in ie if I want to save it. Very bad. 2) no way to load just an image that didn't load once the page has stopped (as with ie)? Must reload entire page. 3) I noticed the other day saving images that they were downloaded again, NOT taken instantly from cache. That's obviously bad. Then again, today on a newer nightly, they seemed to save instantly. Not sure what's going on or when. 4) seems to be some real funkyness with selecting text in a textarea such as this. Often can't put the cursor at the end, and editing get really mucked up. "ENTER" cuts a bunch of text where you enter. A daily annoyance as with this post. 5) the home button is on a useless personal bar, while the address bar is huge. Move the home button up so I can close the personal bar and get some real estate. Let us choose the buttons for the bars. 6) no toggle for full-screen like in ie? Great feature! Or a one button click to close/open all bars together??? I think this is what people mean when they say the link bar is a waste of time that could be better spent on problems that actually annoy users. Or if it isn't, then the above needs to be fixed pronto anyway. -Apart from the above I really like the new moz, especially the tabs. #181 RE: OK as an idea, but I'm more concerned about...by schapel Tuesday October 9th, 2001 8:38 AM To show links, go to View | Show/Hide | Site Navigation Bar | Show Always. Selecting Show Only as Needed might be better, but not many sites support the feature yet. As for the other bugs you mention, try Bugzilla http://bugzilla.mozilla.org/ If you find your bugs or suggestions in Bugzilla, you can vote for them. If not, you can enter them and then come back and tell us where to vote for them. As an extra benefit, Bugzilla uses the Site Navigation bar, so you can see how that works while your searching for your bugs! ;-) #182 Re: OK as an idea, but I'm more concerned about...by saberunit02 Tuesday October 9th, 2001 9:00 AM "5) the home button is on a useless personal bar, while the address bar is huge. Move the home button up so I can close the personal bar and get some real estate. Let us choose the buttons for the bars." It's a matter of personal preference. I prefer accessing bookmarks via the personal toolbar folder than the bookmarks folder and I like having the home button there. The address bar, in some cases, is not big enough when urls are long. It would be smaller if the home button is placed next to it epecially for those with smaller monitors/screen resolutions... You can always disable the personal toolbar and use alt-home or install gestures (http://optimoz.mozdev.org/gestures/installation.html) to access your home page. Gestures are pretty cool. With it you can #184 Re: Re: OK as an idea, but I'm more concerned about...by Tanyel Tuesday October 9th, 2001 9:39 AM Some peoples' personal preference would be to have the home button with the other navigation buttons. That is probably why every other browser in the world puts it there. I think many Mozilla flunkies say they like certain features and dislike other features based on whether Mozilla handles them properly rather than the merit of the features. That is how we get such comments as, "frames suck." #186 Re: Re: Re: OK as an idea, but I'm more concernedby strauss Tuesday October 9th, 2001 12:44 PM I generally agree with you, but in this case, I'd have to say that frames (yet another great Netscape invention) do suck -- it's not just an excuse. They break URLs, but every novice site designer uses them because they're easy. That leaves a ton of web sites where you can't bookmark the individual pages because the frame design doesn't give URLs for frame states. Okay frames suck. To be more preciesly they suck now. I think they were great back then to have e.g. the menu always in reach and the like but these can nowadays be done with CSS fixed positioning and IFRAMES. Btw. besides of the nasty back button problems I think Mozilla is far better supporting frames than any IE. It's features like "Show only this frame" (great for bookmarking a Frame or changing parameters in the URL when developing) and a clear difference between View Frame Source and View Page Source make living in a framed world much easier :) #187 Re: Re: Re: OK as an idea, but I'm more concernedby saberunit02 Tuesday October 9th, 2001 12:46 PM I just stated my personal preference. IMHO, placement of the home button in the personal toolbar is a good idea, because of the space it would take away from the address bar. I never said Moz handles every feature "properly" nor is every feature implemented to my preferences. There are certain features I like in Moz and certain ones I like in IE (e.g., IE's "left-overs" menu to handle overflowing bookmarks in the personal toolbar). Just because I like how Moz handles a specific feature, that makes me a Moz flunky? Please. Using your rationale, then I can assume your an IE flunky. Some links for the bugs you referred to: 1) http://bugzilla.mozilla.org/show_bug.cgi?id=49543 2) http://bugzilla.mozilla.org/show_bug.cgi?id=47475 5) http://bugzilla.mozilla.org/show_bug.cgi?id=49543 blocks the following: http://bugzilla.mozilla.org/show_bug.cgi?id=15144 http://bugzilla.mozilla.org/show_bug.cgi?id=64073 http://bugzilla.mozilla.org/show_bug.cgi?id=89350 Happy voting ! (although votes isn't something of importance for Mozilla.org) gui for no pop-ups. this is a killer feature but most people won't have a clue how to implement it. work with major banks (and other key ssl sites) to get them supported/up to speed. I use citibank and it says I don't have 128 bit encryption, though I do, right? I must open ie to bank. let users add search engines. (and a keyword system as with ie so as to use the search engine you want; then let developers know that they can urge customers to add their site to moz!) tab recall would be very nice bugs: when I open the help from the prefs gui I usually get: Context sensitive help: write me! file: mozilla/extensions/help/resources/locale/en-US/cs_nav_prefs_navigator.html when I alter the display of items on a page and it redraws the page horizontally, remnants are left on the page. (Vertically it seems fine). I must flash the body display in and out to get rid of them. This is a serious bug. What is the problem here? tabs often don't close until done a 2nd time just some ideas based on practical *user* experience with moz. I understand some are being worked on, but solve these - and a few more obviously - and you have a knockout browser. The pop-up pref and tabs are your killer features to emphasize to users alongside the great password/privacy features. They'll hear clear enough that moz has the best css/dom standards, which they'll like, though they won't have a clue what it really means. (One linkbar aside: I don't think many developers will want to bloat their code to add link info that is already covered on the page. I know I won't.) *all using the latest nightlies* figured out how to add my own site's search engine to moz. cool. probs: -tabbing from address bar to search button doesn't work -tabbing from sidebar search term bar to button works, but enter doesn't submit (though enter on search term bar does) -sidebar search term often sticks and won't change. must switch to new sidebar tab then go back. -can't get anyone's search results to come up in sidebar area even with it checked in prefs. how is this done? I searched mozilla.org but can't find it. now if I can figure out how to add my own toolbar... :-) >gui for no pop-ups. Check out http://www.xulplanet.com/downloads/view.cgi?category=applications&view=prefbar >(One linkbar aside: I don't think many developers will want to bloat their code to add link info that is already covered on the page. I know I won't.) And I definitely know I will. Link Tags are a well thougt feature of HTML 2 that every browser should have implemented long ago. Now at least one has and everyone is just complaining even without any proof, that this has slowed down any development on other things. Ever thought that this might have introduced new developers to the Mozilla project? But okay, Mozilla is just a big company and everyone pays a huge amount for the project so everyone has a right to complain. Oh....am I wrong? Is Mozilla just an OPEN SOURCE project where EVERYONE can rather HELP than complain and the rest should just enjoy a FREE product. And the least things everyone complaining could do are filing their complaints as bugs in Bugzilla, spend testcases and giving developers any information possible. Complaining about features helps nothing! Helping fix bugs does! Just an easy rule to follow ;) #201 Provide a list with site that support this featureby bugs4hj Thursday October 11th, 2001 10:04 PM n/t |