Mozilla 1.0 Release Candidate 2 ReleasedFriday May 10th, 2002mozilla.org today released the second release candidate of Mozilla 1.0, in preparation for the final release of 1.0, hopefully by the end of this month. You can grab it by going to the releases page or by going to the ftp site. You can also check out the release notes and a full list of what's new. A brief list of what's new between RC1 and RC2 includes HTTP 1.1 pipelining support, the removal of the link toolbar (for performance reasons, still on in the trunk), and this will be the first milestone release with a fix for the security hole announced last week. Along with this, the main focus has been on stability, and a number of crash and top crash fixes have gone in. Along with the release of RC2, mozilla.org has updated the release roadmap with some rough estimates of what will be happening on the trunk with 1.1, and announcing today's release of RC2. 1.0 is getting nearer and nearer..... but the wait is worth it. :) BTW, did u guys realise that by clicking on the small bookmark on the left of the URL means 'File Bookmark' :) >BTW, did u guys realise that by clicking on the small bookmark on the left of the URL >means 'File Bookmark' :) No, but thanks for pointing it out. That's useful :) Unfortunately, it appears that it is not calling the exact same form or method or whatever as the "File Bookmark..." under the Bookmarks menu calls. For me at least the window it brings up does not include the "File as group" checkbox when there are multiple tabs present. Besides that the window the "File Bookmark..." item brings up is much too small on my machine. Anyone else seeing this? Erm, well it definitely /shouldn't/ have a 'file as group' checkbox. You're clicking on the bookmark icon *right next to a url*, and if that's so it should only do stuff related to that url - anything else would be very confusing. Just my opinion, but I suspect that's the thinking behind it. It would be very counter-intuitive to do anything else. For example, if you dragged that url onto the personal toolbar, it would be total madness if it did anything other than add just the url that you dragged to the bar... Personally, I find it confusing that there's two separate "File Bookmarks" windows. I usually don't use File Bookmarks as a rule. Instead I just "Add bookmarks" and when it gets out of hand (i.e., I have to scroll down them), I organize them into folders or delete them and begin again. So the only purpose that "File Bookmark" has for me, is to create a tab group (which admittedly, I only have a few of). This would have represented a great shortcut if it had a "File as Group" option or acted like an "Add Bookmark" with one click bookmarking. Instead, I'm kind of at a loss of what to use it for, except for the dragging to the desktop (which I haven't thought of in the past). i'm doing l10n, thefore i create langpack for each release (unless i'm lazy). and i dont understand why mozilla always release during the same weekend with F1 GP. Does it really matter though? You know who is going to win before the race starts... unless he's knocked out and then it's the person who is in the lead after the 1st corner. #4 Drivers need to approve one thing...by _rgw_ <webbs@fayette.net> Saturday May 11th, 2002 7:17 AM The changes to the tabbrowser.xml (I believe) that keeps tab's borders from disappearing. Hi, I was using the blizzard 0.9.9 xft rpms for a while, they worked great. However when upgrading to 1.0r1 I couldn't get it to work from source ? Anyone got it to work ? (btw, this is NOT freetype anti aliasing, nor gdkxft stuff) Hi, I was using the blizzard 0.9.9 xft rpms for a while, they worked great. However when upgrading to 1.0r1 I couldn't get it to work from source ? Anyone got it to work ? (btw, this is NOT freetype anti aliasing, nor gdkxft stuff) <http://bookmarks.yahoo.com/> the site looks odd. once I log in it gets worse. everything is compressed. <http://bugzilla.mozilla.org/show_bug.cgi?id=131841> Crash on transition from secure to normal site <http://www.mozilla.org/party/2002/> I guess 1.0 can't be pushed past the 12th of June or it'll be late for the party! :) I've always wondered how much memory Mozilla needs. It seems that it's getting worse and worse. RC2 (Linux version) is unbelievable - after a couple of hours of browsing and several open windows and tabs, here's what "top" in Linux says: SIZE RSS SHARE 507M 240M 13468 mozilla-bin Now, I admit I'm not an expert in this, perhaps "top" is not a good measuring method or I simply don't know what the above output means, but the numbers are incredible. The "free" command suggests that they're perhaps correct. I tried the Windows version - it's faster and doesn't have the strange rendering bugs, but I'm not sure about the memory... Is this acceptable for a release candidate or am I missing something? Mine never grew this big. Usually about 23M initially and around 60M after some heavy browsing. Also, make sure you don't sum up the values of all the mozilla-bin processes. IIRC the memory is shared so you should only count one of them. #50 some broken `top` command on Linux ?by RvR <mozillazine@mozillazine-fr.org> Tuesday May 14th, 2002 2:08 AM Linux is the only OS that counts threads as heavyweight processes. the `top` command should not add each thread's memory, because it's *shared* memory (that's the definition of threads). some versions of `top` are broken. maybe you used one, unfortunately. example output from the `ps` command : RSS TIME COMMAND 28372 0:32 /home/mozilla/mozilla-bin 28372 0:00 /home/mozilla/mozilla-bin 28372 0:00 /home/mozilla/mozilla-bin 28372 0:00 /home/mozilla/mozilla-bin 28372 0:00 /home/mozilla/mozilla-bin 28372 0:00 /home/mozilla/mozilla-bin that means mozilla eats about 27 MB of RAM, not 166 MB ! #51 [reformating] some broken `top` command on Linux ?by RvR <mozillazine@mozillazine-fr.org> Tuesday May 14th, 2002 2:10 AM Linux is the only OS that counts threads as heavyweight processes. Thus, he `top` command should not add each thread's memory, because it's *shared* memory (that's the definition of threads). Some versions of `top` are broken. Maybe you used one, unfortunately. example output from the `ps` command : RSS TIME COMMAND 28372 0:32 /home/mozilla/mozilla-bin 28372 0:00 /home/mozilla/mozilla-bin 28372 0:00 /home/mozilla/mozilla-bin 28372 0:00 /home/mozilla/mozilla-bin 28372 0:00 /home/mozilla/mozilla-bin 28372 0:00 /home/mozilla/mozilla-bin that means mozilla eats about 27 MB of RAM, not 166 MB ! Thanks for the explanation. But I'm not sure if this is the case with my Linux system. I've tried several programs (top, kpm from KDE, ps) and they all show the same numbers - yes, the "507 MB" was sometimes listed several times (as in your example) but it *was* 507 MB. Of course, the number is hardly ever so high, but it's not a big problem to get it over 100 MB or so. The problem is that while I'm using Mozilla it's still growing and growing... Did you try with a clean profile? A few hours ago, RC2 completely messed up my default profile. After that, I noticed that my nightly build (2002050921) was using a lot more memories (40Mb at startup instead of 20Mb and that was growing very fast). That's probably a stupid question but how much do you allow in the memory cache?
There are thousands and thousands of manhours invested to make RC2, and it seems to be impossible that somebody invests the two minutes it takes to update the roadmap everytime something is released? I think it is embarrasing and leaves an unprofessional impression - all the more since the roadmap is linked to from the releases page, this mozillazine article, and often also reports about the release that appear in computer magazines. #20 Re: As usual, the roadmap was not updatedby asa <asa@mozilla.org> Sunday May 12th, 2002 10:36 AM Get over it. --Asa #22 Re: Re: As usual, the roadmap was not updatedby Tanyel <tanyel@straightblack.com> Sunday May 12th, 2002 10:58 AM That response should probably be added to the bugzilla status choices under WORKSFORME. Why use logic when hubris is so effective? Just where is the hubris located? You are being provided with an internet aplication suite at no charge, and yet you and others are quick to demand, not ask but demand, that it be tailored to suit you. Contact Mozilla.org and vol your time as the page updater. Fork the code and start your own project from it. That's how open source works. You don't have to accept what the coders do, if you don't like it submit a change if it isn't accepted, then go your own merry way with your own project. If you are dying and in need of urgent resuscitation I might be of some assistance but as a coder I doubt I would be of much help. I have nevertheless used most nightlies for over a year and thus given feedback. Just because a question is not phrased in the most considerate manner does not mean the question is invalid. Rather than being unresponsive and dismissive, ignore the question or better yet justify the questioned behaviour with a logical argument and maybe a solution that benefits Mozilla would emerge. A role for supporters without arcane programming skills? shipdoc HTML isn't hard to learn, certainly not the rather basic skills needed for simple pages like the ones on Mozilla.org's site. Updating out of date pages and submitting them would free up time for somebody to code. (The complaint at the top of this thread could be fixed by simply replacing the dated text in the page's code) Help is allways needed with verifying bugs that have been fixed, or confirming unconfirmed bug reports. With a little HTML you can edit a page that is causing problems to create a test case for the coders to work with. There are almost certainly dupe bugs that haven't been caught yet, and old bugs that were "acidentally" fixed while working on a related bug. Identifying these would be helpful. If you are multi-lingual you can help with the translation projects to create lang-pacs for Mozilla. You don't have to be a uber hacker to work on Mozilla, though you will need more patence than I have to wade through the burecratic maze that has grown up over the years, which is why I'm working on Aphrodite and other projects instead of Mozilla. Last of all if your help is ignored by Mozilla.org, there are plenty of Mozilla related projects on Mozdev that could welcome some constructive help. BTW as a nav vet, I do applaud the skills of "shipdocs" "You are being provided with an internet aplication suite at no charge, and yet you and others are quick to demand, not ask but demand, that it be tailored to suit you." What are you talking about? Nobody demanded anything here. Someone simply pointed out that it sucks that the roadmap isn't updated whenever there's a relase. Personally I don't think it's a huge deal that the roadmap web page isn't always up to date within 30 seconds, but there were no demands at all in the original post so I don't see what you're crying about here. With testing crowds of 400000 people (that's the number of downloads of RC1 from what I've heard) there are bound to be a couple of people who aren't entirely happy and who haven't got the best verbal skills and demand things with harsh language. This is to be expected whenever you're shipping software to large crowds of people - hell, even to small crowds of people! But that's completely off topic for the parent post where nobody was demanding anything - merely posting an opinion. Its just unprofessional. I dont mind. But as this is a document that often linked to, a lot of people will get a bad impression. And to whoever braught the old "dont demand things from a free product" argument: well, I did not demand. But even *if* I did: this is a free product because many people contribute (if only with small) to it for free. These people might have a right to ask for little, tiny things like this. Even if they know they have no right to see it happen ... PS: the roadmap is still not updated :) When I updraded from RC1 to RC2, I found that a major feature has been disabled. I am unable to save any pictures or web pages from the browser which is important for me. I'm forced to go back to RC1 until the problem is fixed in RC3 or if somebody have a fix I can use. Thanks in advance. It works for me, strange... I use Win ME. Can you be more precise ? You posted the same claim on N.P.M.seamonkey and failed to reply to requests for more information on a problem that no one else seems to be able to duplicate. If you are really having a problem I would suggest that you file a bug that contains the information needed to duplicate your problem or it won't be fixed in rc3 or Mozilla 1.0 or even Mozilla 2.0. Do you think the Mozilla hackers are psychic? Give them the details via Bugzilla instead of bitching in newsgroups. Hi! I have a very similar problem using MOZ RC2 ! If i get an e-mail with a link to an image on the web and right click-"Save Image as" no save as dialog appears... If i "copy Image Location" and use it in a new browser window i can save it. Hope it helps Hope you can fix it Is there any switch to turn it on again? I think it was a very useful feature. Wenn browsing a howto for example i've used almost only this bar. I know there were problems with the tabbed interface but i could live with it. So if it's not a big issue please enable it in the 1.0 (at least through prefs.js) It was pulled from rc2 because it was affecting startup time and new window creation time. The code is parsed even if the page contains no links. It's still in the trunk builds. This bug details the problems <http://bugzilla.mozilla.org/show_bug.cgi?id=102992> This fixed bug is the one that removed it <http://bugzilla.mozilla.org/show_bug.cgi?id=138496> To get it back you have to edit navigator.xul in the comm jar, adding this line <?xul-overlay href="chrome://navigator/content/linkToolbarOverlay.xul"?> There is an untested xpi attached to bug 138496 that is susposed to restore the toolbar, but it was created on May 1, so it backs out any bug fixes made since then. It wouldn't be hard to create a new xpi that restores this feature, but I wouldn't advise creating it until after 1.0 is released so it dosen't back out any other bug fixes. The converter turned most of the line that has to be added into a link, mouse over it to see the remainder of the line in the status toolbar. The XPI, if it works at all (and I've had a couple of confirmations that it does) will work perfectly well with all releases up to 1.0 and beyond. It essentially performs the one-liner fix of adding the overlay - and it USES the overlay file that's still part of the Mozilla build. In other words, it doesn't back out anything; that's just FUD. Of course, it won't get any fixes made on the trunk - but neither will any other part of Mozilla for 1.0. The issues with the xpi as it stands right now are: - Won't install into your profile directory, but into your global mozilla installation. This makes it useless for most linux people - including myself ;) - Doesn't fix the problem with tabs; an ideal implementation would install a new tabbrowser.xml and override the binding to use it. That's a little bit more work... - And it would be nice if the XPI was part of the build so you could check a checkbox in the custom installer to turn it on. - Also would be nice if the SiteNavBar were turned on by default if you did - don't know how to do that because it would require a change to the overlay file, which I don't think you can do in an XPI. But from what people tell me, it *does* work, and it'll get you the SiteNavBar exactly as it is in prior branch builds. The best way to handle this would be a XPI that replaced comm.jar with a revised copy that included navigator.css with the "missing" line restored. This would also allow you to modify the overlay to have it turned on by default and fix anything else in comm.jar that was needed for the toolbar. This would make it work on Linux, but would back out any changes made to comm.jar after the xpi was prepared. so it's best to wait for 1.0 to make this kind of fix. Does anyone know what happened to the relicensing-process? Didn't hear anything from it recently. When do they expect Mozilla to be completely GPL/LGPL? (I think it would be a great thing if 1.0 could be) Mozilla is not going "completely GPL/LGPL" - it's going [M|N]PL/LGPL/GPL triple. We would have liked to get it done by 1.0 but it was just too big a job. It's still being worked on. Gerv Anybody know what Mozilla this version will be based on? <ftp://ftp.netscape.com/pu…/netscape6/english/6.2.3/> It'll be 0.9.4.1 again, just with a few bug fixes (mainly the XMLHttpRequest security hole). Alex LinuxFormat was the UK's first linux magazine (and still most popular I think). Next month their main cover feature is on Mozilla 1.0. From an advert in PC Plus: "ATTACK OF THE KILLER WEB BROWSER! As Mozilla 1.0 appears (hopefully!) we'll be taking a look at not only the biggest desktop app ever written, but how the Mozilla project has changed the world, and the technologies and spin-offs it has spawned." June issue on sale Friday May 24. <http://www.linuxformat.co.uk/> (and no, I don't work for the publisher) #40 Uninstallation problem of RC1 after installing RC2by MonteCristo <monte@gmx.net> Monday May 13th, 2002 11:35 AM A strange problem I haven't encountered with previous Moz releases: after installing RC2 (with RC1 still on my HD), there's still only one 'remove Mozilla (1.0)' in my Add/Remove list (I'm using Win98). And strangely enough, running the uninstall removes *RC2*, not RC1. Is this a bug or did I mess something up? you messed up and yes its a bug.. the issue that happens is that your files for RC2 are the same directory and filenames as RC1 so if you run the uninstall first you wont have a problem.. if you run it after you do. #60 Re: Uninstallation problem of RC1 after installingby MonteCristo <monte@gmx.net> Tuesday May 14th, 2002 9:17 AM OK, thanks. I'll try that. Does anyone else bemoan the loss of the edit link in composer feature that was present up until RC1 (and in all the netscape browsers). This was (for me anyway) a really really useful feature which for some unknown reason the UI design team decided to take out. I opened a bug in bugzilla to see if it could be put back but no luck. This bug lasted less that 24 hours (which didn't give any time to amass votes towards it). I was under the (prehaps mistaken) impression that bugzilla held design request as well as bugs. Anyone got any insight on this? Doesn't file->edit page work? It was removed from the context menus because it isn't really context sensitive. The menus were too long and had a lot of items which didn't really need to be there. Some items had to go and that option was, apparently, one of them. #52 Re: Re: edit link in composer - disappearedby SubtleRebel <mark@ky.net> Tuesday May 14th, 2002 2:39 AM Actually "Edit Link" would be context sensitive. Nope, did never use that one. What I wanted was to move the new "this frame" up a few menu items. But no way, it's below the (by me) never used view background image.... It's funny they say Mozilla is not for end user but developers. Every web developer needs quick access to frame info. *shrug* The bug is <http://bugzilla.mozilla.org/show_bug.cgi?id=138400> in case you want to vote for it :-) Erm, Mozilla /isn't/ for web delevopers, but for *browser* developers. Web developers count as end-users if they're using Mozilla for testing purposes... I see, though I'd guess that there are only few browser developers out there. And these would be working on other browsers (IE, lynx, ...). Anyway, a web devloping user that deploys Mozilla for testing benfits from support for common web practices like frames. I have the empression that mpt and others hate frames, but I think it is patronizing to make the access to that info hard to get by. This is ok for Netscape releases, but sucks a Mozilla release. Yeah, if anything Page Info should be in a level and Frame Info should be on the main level when in frames. For RC1 I created a zipfile with three changed files and instructions for getting 0.9.9 style contextmenus back. I've updated this for RC2 (deleted one line from one file, that's all that was changed between RC1 and RC2 in those files) <http://juima.org/stuff/rc2contextmenus.zip> These menus aren't ideal - far too large in many instances; but removing items from them is a lot easier than adding items, so I'm providing it this way. At least this way you get far easier access to the essential options "reload frame" and "view frame source" (as well as the infinitely useful "show only this frame" and "open frame in new tab". (Oh, and back, forward, reload and stop appear everywhere they did in 0.9.9 as well.) I probably should go and write an .xpi for it (at the very least to allow many non-savvy webdesigner friends I have to get their favorite contextmenus back), but don't think I'll get around to that anytime soon. Why is Moz so slow on <http://www.go-mono.org> The site seems pretty basic. BTW, Opera slows down as well, but IE flies through it. It uses a fixed background. So on a slower computer, scrolling is not nearly as quick as if the background scrolled with the text. Seems fine on my machine and as far as I can remember it works well enough even on slower systems, but file a bug if it's really that bad. I would not say it affects only slower computers. On this p3 730 MHz with W2K workstation, scrolling in both ie and mozilla is a bit chunky. In mozilla, a bit more. Of course now you can debate what is slower these days, but I put the line at about 400MHz. I am using a P4 1.8GHz with WinXP and Mozilla1.0RC2 and IE6.0 both scroll the same on <http://www.go-mono.org> Nothing about Mozilla should be slow on 1.8 GHz, at lease I sure hope not. buy an athlon :) well they should kick thouse images from the background i observed that on windoze and p3-600MHurtz is very slow but on the AMD 1200-Mhz is working fine (linux) You are right. The background gif is 4k, but it is highly compressed (uncompressed size 1.2mb) and huge in size. Is there anyway to force Moz to skip the background image? Actually something does not make sense. If I save the web page locally and load it, it flies through it with fixed-background, etc... If I run it from go-mono.org it is very slow. What features are planned for 1.1? I could not find it in the roadmap. You know, I'm curious about this too. What I know is going in pretty soon (but definitely AFTER 1.0 releases) is bug 129115 ( <http://bugzilla.mozilla.org/show_bug.cgi?id=129115> ). That's the new dhtml engine, which does to mozilla dhtml what pressing the accelerator does to a ferrari. IE is still faster though (gotta have respect for the IE programmers, they built a fast browser). There are benchmarks of the new rendering engine there. Pretty impressive, if they're accurate. And then there's the spellchecker (go see on mozdev.org). That will probably go in before 1.1 too. You can always run a query on bugzilla for all the bugs that have the mozilla1.1aplha, mozilla1.1beta, or mozilla1.1 keyword set (currently over 1200 bugs). That doesn't tell you much about what will be in 1.1 since a lot of those are going to get retargeted, but it's useful as a guideline ofcourse. I've been looking through them, and cherry-picked some of the ones that jump out at you: <http://bugzilla.mozilla.org/show_bug.cgi?id=66054> Ability to view rss feeds directly, and place them in the sidebar (without adding some special sidebar app) <http://bugzilla.mozilla.org/show_bug.cgi?id=66822> Implement ROT13 - someone has way too much time on their hands here :) <http://bugzilla.mozilla.org/show_bug.cgi?id=75915> A way to allow you to block all cookies except those coming from pre-allowed sites. You set up which sites you want cookies from once, and don't worry about them ever again. I like it, and it's needed for IE functionality parity. <http://bugzilla.mozilla.org/show_bug.cgi?id=126685> full-screen mode. Remember, none of these are guaranteed to make it into 1.1. There are also a few bugs relating to beonex's funded development of roaming support (keeping your bookmarks and cookies on a central server), which should make it into 1.1 for certain. Not that I use that stuff, but supposedly there are scores of users out there who do. Hooray for them. On the above site, Mozilla (trunk or RC2) scrolls noticeable slower than IE6 on my 400MHz-Win2K machine. But it is still acceptable. You may see quite different results because of specific graphic os/video hardware/driver configurations. It is not only the processor that affects scrolling speed. <http://bugzilla.mozilla.org/show_bug.cgi?id=100951> is a "meta" bug for slow scrolling problems. What HTTP 1.1 pipelining actually is and why I should/shouldn't enable it? <http://www.mozilla.org/pr…/http/pipelining-faq.html> You should enable it because it can speed up browsing. You shouldn't enable it because it's the cause of the top two crashers. Alex but it looks like they are both fixed (bug 141796 and bug 143821) I thought it'd be easy to use tab browsing, but after installing Moz RC2, JS links don't open in either new tab or window. I can understand the latter since I disabled it in Advanced -> Scripts & Windows, but I can only open in new tab if I right-click and choose open in tab. Is that how it works? Even this doesn't work with JS links (links taht call JS's new window command) though. Any help would be appreciated. Oh, and how come it takes so long to go to another page, eg. when I click the back button to go back to the starting page. Is there a help site somewhere? #83 Mozilla lacks font tag?by schectex <schectex@math.vanderbilt.edu> Saturday May 18th, 2002 9:19 AM MathML is a rather complicated way to post math on the web. For quick and dirty symbols, I'm accustomed to using the "font face=symbol" tag. That was available in Netscape classic and in M$IE, but it was taken out of Mozilla. Is it too late to try to persuade the organizers to put that back into Mozilla? Eric Schechter (<eric.schechter@vanderbilt.edu>) The Symbol font is Windows-only, IIRC. Try using HTML character entities for mathematical and related symbols: <http://www.w3.org/TR/html…ml/entities.html#h-24.3.1> |
|