View source for Talk:Mozilla 2/Old Moz2

Planning for 2.0? Why don't you fix --enable-boehm in configure. Right now, it doesn't build without manuall adjustment to half a dozen Makefiles and then coredumps during startup. Mozilla leaks like a seive, losing track of about 60 megs of RAM a day under heavy usage. Having tabs, it's easy to leave it open continiously and painful to close all the tabs, restart the sucker, and reopen the tabs every day. I know it takes a long time to scan a 300 meg heap but when you have a 300 heap on a system with 128 megs of RAM it's much, much (much) faster to garbage collect than to leak. Or perhaps Unix is becoming more like Windows where you're expected to restart daily. I don't know. 

Generally speaking, most configuration option permutations don't result in a working binary. Even more generally, Mozilla doesn't build under NetBSD and most other systems and it's hard to get a working binary on Linux. If thething is mature and stable, shouldn't the build system be passable? And everyone thought Ultrix was going to be around forever, then they thought SunOS was going to be around forever. Now writing "portable" code seems to mean "we targeted Linux but there are some #ifdefs in there for other systems". Bah! Trying to build this thing on NetBSD is a nightmare. pkgsrc updates it once a blue moon (they're still trying to get Mozilla 1.3 going) and it never builds anyway, even with the pkgsrc patches. What if the next big OS is far more different than NetBSD is from Linux? Most of the problems are activations of dead code and overly complex autoconf crud. This goop is entirely unnecessary. 

While I'm at it, here are some more annoyances. Let me set cookies to automatically be accepted but time out on the end of the session. Build in the hack that saves which tabs you had open when it crashes. The hack hasn't been updated in ages but everyone keeps boasting about it as if it still exists. Put it in core so it'll be maintained. Mozilla crashes way too often not to have this. Fix that bug that dates back to Netscape 1.1 where the thing will go to 100% CPU usage and sit there and need to be killed from the console. Make a button I can add to the navigation to turn JavaScript on and off quickly. Some sites don't work without it, some site don't work with it, but few are neutral. Or make JavaScript a checkbox on one of the drop-down menus. Until Mozilla has 90% market share and everyone who isn't maintaining the website starts actively maintaining it again, we poor users are going to have to toggle JavaScript constantly. Some of us working stiffs don't have the luxory of hanging out only Mozilla-friendly sites. 

(I don't mean to troll here - there are serious nits to me as someone who has been on the 'Net since 1990 and dealing with browsers since gopher and CERN linemode. Year after year I download sources at release announcements and am disappointed by stability, configurability, and general brokenness. After 14 years, I'm entitled to be a grumpy old man who is more than a little cynical. So, in a nutshell, for 2.0, I suggest making the things that are supposed to work already actually work. The nicest features are the ones people keep pretending like they have when they don't - the ones we thought we had a long time ago. It's hard to get excited about "new features" while dealing with this crud.)

- Scott Walters scott@slowass.net