MozillaZine

Tree Closes For 0.9.8

Wednesday January 16th, 2002

Mozilla.org has closed the tree to approved checkins only, starting as of 12am Wednesday, and will do so until 0.9.8 has branched. 0.9.8 will have a variety of new items including new natively drawn widgets on WindowsXP, Mac OS X, and GTK, when you are in the classic skin (We will have more on this later, including screenshots); the addressbook was rewritten, and now supports printing, a new "Get Map" button allowing you to query for a map based on a card address, and other stability fixes; Windows MAPI support; and a huge amount of performance and stability work.

Many believe this is one of the last milestones prior to 1.0, and that Mozilla.org will actually have 1.0 following 0.9.9. 0.9.8 should branch sometime next week, with a release two Mondays from now. We'll keep you updated on both the branching and the release.

#1 GTK really?

by sab39

Wednesday January 16th, 2002 1:12 PM

Looking at the native theme support tracking bug 117584 http://bugzilla.mozilla.org/show_bug.cgi?id=117584 the only GTK native theme support is currently for Button. So I'd be slightly surprised if full theme support on GTK will be in 0.9.8, although very happy :)

Can't wait to see the screenshots of this :)

Stuart.

#2 Stability

by WillyWonka

Wednesday January 16th, 2002 1:25 PM

I don't know about anyone else, but the number of working features in the nightlies has been going down. Print preview locked up the browser the one time I tried it. A couple days ago chatzilla stopped working. Today, icons aren't displaying properly in mail (classic skin), when I open a compose window for the first time, it gives me an error telling me to try again. That sorta stuff. I hope they have these things sorted out on the branch.

The get map button works though. Well the 2nd time I tried it... map quest was down the first time.

#5 Re: Stability

by omidk

Wednesday January 16th, 2002 2:26 PM

you should use the milestones if that bothers you. i used to try to be cutting edge but really the new features that they add are not worth the stability of the milestones. The sad thing though is that nothing is like a netscape release. 6.2 is rock solid for me but no tabs so i am stuck with .9.7 ;)

#16 Re: Stability

by WillyWonka

Wednesday January 16th, 2002 6:27 PM

It's not that it bothers me in the nightlies (I keep backups of stable versions). It's just I hope they have them fixed when they release the milestone. I've just been watching it go downhill for the past week or so and I hope they don't show up in the milestone. It creates a bad image for the project.

#30 Re: Stability

by mcelrath

Thursday January 17th, 2002 8:57 AM

I agree, I hope they do a better job with 0.9.8 than they did with 0.9.7. It crashes on me several times per day on linux. I\'ve gotten so annoyed at it that I\'ve actually switched to galeon because it\'s bookmark handling is superior, bookmarks are important to me, and mozilla\'s bookmark editor is STILL broken. Come on guys, let\'s make sure 0.9.8 is rock solid and at least doesn\'t crash. (Note on the other hand 0.9.6 was great -- it never crashed on me)

#89 Re: Stability

by flacco

Sunday January 20th, 2002 7:45 AM

>> I agree, I hope they do a better job with 0.9.8 than they did with 0.9.7. It crashes on me several times per day on linux. <<

Ditto - shuts down for now apparent reason.

#103 Re: Re: Stability

by MozSaysAloha

Tuesday January 22nd, 2002 12:25 AM

All of the Mozilla builds I tried have been stable...Print preview works well. The only time Mozilla has crashed on me was when I was clicking on Print Preview before the page had finished loading. Besides that, the Mozilla builds I have used have been stable.

#3 Native widgets

by jwb

Wednesday January 16th, 2002 1:42 PM

Wow, native widgets are huge. Once upon a time everybody said native widgets were impossible because of CSS concerns and oh what about the way we do compositing and layout and so forth. But now we are getting them. That's just great.

#7 Re: Native widgets

by joschi

Wednesday January 16th, 2002 3:18 PM

<http://bugzilla.mozilla.org/attachment.cgi?id=64512&action=view>

this is looking really nice.

#36 Re: If it were my site you'd be staring at ads gal

by CatamountJck

Thursday January 17th, 2002 10:42 AM

Hm, no link?

#51 Native widgets rock!

by kaldari

Thursday January 17th, 2002 6:51 PM

Thank you Mozilla Team! All those mean things I said about you guys I'm taking back now ;)

#4 Don't tease like that!

by aganguli

Wednesday January 16th, 2002 1:43 PM

GTK native widgets would rock!!! Is this really possible? Links anybody?

#8 Re: Don't tease like that!

by joschi

Wednesday January 16th, 2002 3:19 PM

http://bugzilla.mozilla.org/attachment.cgi?id=64512&action=view

this is looking nice.

#9 Damn that's sexy!

by mpercy

Wednesday January 16th, 2002 3:36 PM

Sweet! I love it! "You can do it! You can do it all night long!"

Man MacOS X is almost too much for me... maybe I will go buy one of those new iMacs... ;)

Go Moz! Native widgets rock!

--Micko

#17 Re: Damn that's sexy!

by WillyWonka

Wednesday January 16th, 2002 6:32 PM

I don't think they are native widgets. I believe they are skinned versions of the mozilla widgets which use the textures provided by the system, so you can only get the aqua skin on a mac system and you can only get the winXP skin on a winXP system.

I think thats how it works. Gets around the legal problems while still looking like other apps.

#21 Here is a WinXP Screenshot (MacOS X theme)

by jrt

Wednesday January 16th, 2002 9:11 PM

I tried to recreate the OS X screenshot (http://bugzilla.mozilla.org/attachment.cgi?id=64512&action=view) on my Windows XP machine using the new natively drawn widgets and the StyleXP based AquaMax theme.

I think it turned out pretty well...except for the transparency, and some minor differences. Note that my screenshot is using Cleartype anti-aliasing, so the text might look a little weird on a CRT monitor, but it looks incredible on a LCD screen - better than the OS X screenshot, actually.

Anyway, here is my screenshot - http://www.loodi.com/XPTheme.png (161kB, 1138x1017 24bit PNG)

#23 AquaMax theme?

by foamy

Wednesday January 16th, 2002 9:56 PM

Where can I get the AquaMax theme? The get new themes link is pretty useless.

thanks

#26 Re: AquaMax theme?

by jrt

Wednesday January 16th, 2002 10:56 PM

> Where can I get the AquaMax theme? The get new themes link is pretty useless.

AquaMax is a Windows XP theme(*), not a Mozilla theme. There was an Aqua theme for Mozilla once upon a time, but Apple's lawyers shut that project down. Also, it wasn't as nice as the native widgets and a good XP theme.

But this is a good illustration of why native widgets really are useful. Mozilla, when using the Classic theme, will use whatever theme the OS is using. I could switch themes in XP, and Mozilla would automatically match appearance (buttons, scrollbars, etc). There will still be a place for Mozilla themes, but if you just want to match appearances with the rest of your applications, natively drawn widgets are a Really Big Deal.

(*) In order to use non-Microsoft approved themes (such as AquaMax) on XP, you first need to install a program called StyleXP http://www.tgtsoft.com/Download.html . Install StyleXP, then download themes from the net. One good site, which is currently offline, is themexp.org http://www.themexp.org/ I downloaded AquaMax from themexp.org

#31 Re: Here is a WinXP Screenshot (MacOS X theme)

by hfx_ben

Thursday January 17th, 2002 9:17 AM

Thanks for the screen shot ... I used it to work up something I'm looking for. Not sure this is the place for it but ... am I the only one who wants "Icon Only" in Classic? (Hasn't that been an option since Mosaic?!)

Anyhow, I found that whatchamacallit throbber is oversize ... here's a peek:

http://turtle.indymedia.org/~hfx_ben/throb.html

hfx_ben

#6 Not everybody happy...

by pirat

Wednesday January 16th, 2002 3:05 PM

I hoped for a long time that remaining OS native things will be kicked out. Instead of that they penetrating more and more inside Mozilla now...

#10 Re: Not everybody happy...

by beastie

Wednesday January 16th, 2002 3:48 PM

They're still XUL widgets, they just use the native theme interfaces to determine how they should look.

#19 Re: Re: Not everybody happy...

by pirat

Wednesday January 16th, 2002 8:19 PM

Sounds better. If it will be an option. But in that case - when anybody finally kick off that piece of crap calling itself "OS native file-picker"? ^_^ Personally that's horrible when during work with differently (but very good) looking program you sometimes get something completelly OS-related. (Especially when it's something like filepicker. I have feeling sometimes OSs are competing who can do it worse ;-) If I remember it right there was idea of filepicker XUL tag but never got in implementation further than an empty block and died soon after it...

#39 Re: Re: Re: Not everybody happy...

by dave532

Thursday January 17th, 2002 11:23 AM

Well the XP (as in cross platform, not WinXP) filepicker is used in the Linux/UNIX builds but not anywhere else. The native filepickers on Windows have features that is currently not implemented in the XUL based XPFilepicker so they use the native file dialogs. I'd rather stick with the native dialogs unless the XUL ones can replicate every bit of functionality as the native ones. This is all a lot of extra wotk though.

(e.g. the Win2k filepicker has a set of links down the left giving shortcuts to common locations and it has autocomplete in the entry box.

#99 unbelievable

by pbreit

Monday January 21st, 2002 5:08 PM

virtually every single computer user on the planet does the vast majority of thier computing on one computer and are totally familiar with the OS's filepicker. it's idiotic to standardize this across OSs instead of across apps on a single OS.

#40 I hate non-native file pickers

by grayrest

Thursday January 17th, 2002 1:52 PM

I'm used to the native windows filepicker, the newest iteration isn't too bad. The problem with non-native file pickers is that I set up my computer so that the stuff I need to get to is as few clicks deep as possible. Usually that means either going from the desktop or the my documents folder, neither of which is near the directory root. I therefore find non-native file pickers incredibly annoying, plus I use the file picker to create folders and delete files in addition to choosing which files to open. I know that defies the orthoganality (sp?) of the file picker, but it's convenient and a feature I like. I could care less how the filepicker looks.

#115 it is an option

by beastie

Tuesday January 22nd, 2002 2:31 PM

"If it will be an option"

It's optional, sure. If you use the Classic theme you get it, Modern you don't.

#118 Re: it is an option

by pirat

Tuesday January 22nd, 2002 5:09 PM

But for how long? ^_~

#11 Native widgets (NOT!)

by bzbarsky

Wednesday January 16th, 2002 4:14 PM

People seem to think that Mozilla is getting native widgets. It is not. What it is getting is that on platforms where an existing theme engine exists all XUL widgets in the classic skin will query the platform-native theme engine for their correct look.

This means that the classic skin will attempt to follow the current theme as much as possible (much more than it used to before the checkins).

Note that Windows other than WinXP does not have a theme engine, hence Mozilla not doing any "native widget" stuff there.

#12 just a quick question

by Tanaaln

Wednesday January 16th, 2002 5:12 PM

Well, first off, I got a build today, and the only 'native' xp thing is that the menus have shadows (umm... yay, I guess). Anyway, though, my real question is, I upgraded to XP a few hours ago, and everything is fine except that mozilla seems to have lost my profile. By making a new one in profile manager it will start, but all my bookmarks, etc. are gone. I can still use my old profile in 6.2, but moz tells me the folder can't be found or something. Can I copy the stuff from 6.2's folders, or what?

Thanks in advance if anyone knows the answer. ;)

#18 Re: just a quick question

by AlexBishop

Wednesday January 16th, 2002 7:09 PM

Remember that profiles are stored in a different location under Windows XP. The new location is C:\Documents and Settings\<Windows User Name>\Application Data\Mozilla\Profiles. Just move the folder containing your profile there and rename it 'default' (no quotes). Then run Moz and it should pick it up. Worked for me, anyway.

Alex

#13 just a quick question

by Tanaaln

Wednesday January 16th, 2002 5:15 PM

Well, first off, I got a build today, and the only 'native' xp thing is that the menus have shadows (umm... yay, I guess). Anyway, though, my real question is, I upgraded to XP a few hours ago, and everything is fine except that mozilla seems to have lost my profile. By making a new one in profile manager it will start, but all my bookmarks, etc. are gone. I can still use my old profile in 6.2, but moz tells me the folder can't be found or something. Can I copy the stuff from 6.2's folders, or what?

Thanks in advance if anyone knows the answer. ;)

#14 Well...

by Kovu

Wednesday January 16th, 2002 6:04 PM

If you chose to upgrade to NTFS, that could be the problem. NTFS will brutalize most things that were installed under FAT32.

JR

#15 how to fix

by jsgremlin

Wednesday January 16th, 2002 6:25 PM

hmmm... if the ntfs thing is the problem, I suspect what happened (without any real knowledge) is that netscape was the original creator of your profile files (or maybe just the first to access them after you upgraded?) and so it's the only one that has access now. Also, possibly NS is still running in the background with the "quickstart" feature and is locking access to the files? That's very much conjecture based on my limited info about ntfs (basically, just that it has real file permissions like fat32 doesn't). If you can modify the file permissions (I haven't the slightest idea how to do this - I'm running win 2k with fat32), try making all your profile files read/writeable by everybody. Mozilla will crash/hang/have major issues if it can't write profile files (I know this from having restored my profile from CD--all files come back read-only until you change them). If all that is too confusing or too much work, the answer is yes, you should be able to just copy the files, though you may still have to modify the permissions (I don't know). I have performed much wizardry on my profile (esp. with bookmarks killed by kmeleon and mail/news bugs) by screwing around with the profile files.

-Joshua <><

#20 Whoa! Calm down, dudes...

by Kommet

Wednesday January 16th, 2002 9:04 PM

Tanaaln, just read the reply to your "other" copy of this post. The correct answer is that the default "Application Data" folders have moved out of the System directory (c:\Windows\ for most) and into a user-specific folder. This is how Win9x/ME with one user differs from WinNT/2K/XP with any amount of users.

To jsgremlin and Kovu, that's a nice thought but a REALLY wild-ass guess. I'm not trying to flame or sound critical or even ruffle feathers, so don't take this the wrong way. Tanaaln did ask if "anyone KNOWS the answer" (emphasis mine), and so maybe taking a shot in the dark stab wasn't the best of help to give.

If anyone thinks I'm being bitchy for even writing this, know that I do Tech Support for a living. If you do, too, then you understand. If not, let me just say that I have a pet peeve relating to wild guessing, and leave it at that.

By the way, jsgremlin, the answer to YOUR problem is to hilight the top level directory you want to change permissions for, right-click, choose "Properties", go to the "Security" tab, and click "Add". A new window will open. In the bottom area, type "every" and hit "Check Names". It should fill in "Everyone" for you. Click "OK" to close that window. Hilight "Everyone" in the Name list and check all the boxes down below. Click "Advanced". Hilight "Everyone" and check both boxes at the bottom of the window. Hit "OK" then "OK" again and watch the fur fly. When everything is done, "Everyone" will have total access to this folder and all its sub-items (folders and files). Make sure the "System" user also has full permission.

Cheers, Kommet

#45 Re: Whoa! Calm down, dudes...

by Kovu

Thursday January 17th, 2002 3:06 PM

Yeah, you're being bitchy. I figured if he "upgraded" WinME with WinXP, it is "very" possible that the original application data is corrupted. I've had it happen. The data is listed in directories but it is completely inaccessible and therefore utterly useless. Anyway, thanks for bashing me around. Always a pleasure.

James

#96 Off topic : My Wild Guessing Tech Support story

by SubtleRebel

Monday January 21st, 2002 12:11 AM

I have had many problems with people trying to guess answers to my technical issues when they really did not have a clue. If someone is honestly trying to help then I can appreciate that, but they should also predicate their suggestions with "I really do not know, but maybe ..." It is always annoying if they state their suggestion as if they KNOW that it is the right answer. It is even worse when they go so far as to argue with you when you tell them that their suggestion is wrong.

One of the worst cases I have experienced was with AOL....

A while back I was configuring a firewall on a T-1 to the Internet for a client; there was a VP who was using AOL and so I had to open up the necessary ports for it, but I could not find any info anywhere on the web what ports AOL's software used (it is now on the AOL website, but it was not there then). Since I did not have a packet sniffer handy, I called AOL's tech support line. I ended up having to spending several HOURS calling several times because I kept getting ignorant answers.

A few of the answers that I was given :

1) We do not use one. 2) I can not tell you because that is an AOL trade secret. 3) It is randomly selected each time you start the AOL software.4) No one here in technical support knows; you would have to talk to the programmers, but they don't have phones. 5) You do not need to know the port number. It should go through the firewall automatically. 6) We can not help you with that, you need to talk to your network administrator. It is up to them to configure the firewall. (Me: I am the one trying to configure the firewall and I just need to know what ports the AOL software uses.) Well, then you need to call your Internet Service Provider. (Me: I am with the ISP) Sorry, we just can't help you if you do not know what you are doing.

What was extremely annoying was that no one would admit to not knowing the answer. They all insisted that what they were telling me was THE correct answer. Most of the people refused to transfer me to any higher level support and some said there were no supervisors or higher level support. Finally I got totally fed up and told a woman that "This is just bullshit!" She replied that there was no reason to use that kind of language (she acted as if it was the worst cuss word she had ever heard) and that if I could not be polite that she was going to transfer me to the "irate caller line" where they were trained to handle people like me. After being on hold for a minute or two, a man came on the line and said "I understand that you are unhappy with the support that you have received, how can I help?" I told him that I just needed to have someone tell me what TCP/IP port or ports were used by the AOL software. He immediately replied "We use port 5190." I politely said thank you. He asked if that was all that I needed. I told him yes unless he could also explain why I had to go through so many people making up answers out of thin air in order to finally get such a simple question answered. He had no answer for that.

#22 native widgets are truly native

by strauss

Wednesday January 16th, 2002 9:35 PM

Looking through the code, one finds that in the nsITheme subclasses, the OS is being called to draw the widgets. These are not XUL widgets that are making calls to determine foreground colors and the like -- they are fully native widgets. On the Mac, this is being accomplished by calling the Appearance Manager to draw them. On GTK, the GNOME toolkit is being called for drawing buttons, not just for coloring buttons drawn in XUL. The Windows code is difficult to understand since it indirects everything through a non-described DLL, but it seems probable that the same implementation strategy is being used on all three platforms.

For instance, with respect to GTK, look at the routines in nsNativeThemeGTK.cpp, which call native GNOME routines like gtk_widget_set_rc_style, gtk_widget_realize, and gtk_button_new. These are not just theme attribute queries used to "fill in the blanks" of XUL-rendered widgets -- they're native OS widget calls. Similarly, in nsNativeThemeMac.cpp, native MacOS Appearance Manager calls such as DrawThemeButton, DrawThemeWindowHeader, DrawThemeEditTextFrame, and DrawThemeTrack are being used for rendering. I'm not sure why some people are insisting that XUL is still being used as the rendering layer for native widgets, but the code shows otherwise on GNOME and Mac at least.

#24 True on OSX

by foamy

Wednesday January 16th, 2002 10:41 PM

I just installed a new theme for OSX which removes all of the horizonatal lines. After launching the new moz, there are no lines (there are with the defaults OSX install).

Changing to graphite in system preferences also changes the widgets from blue to graphite immediately. Hence the widgets are indeed native.

#53 It all depends...

by Millennium

Thursday January 17th, 2002 9:07 PM

At the moment, soome of the widgets are \"truly native\", while others are not; they just call the Appearance Manager to see what the background ought to look like, and then draw that.

Two examples of true-native widgets are scrollbars and progress bars. Thr progress bar ripples as it should (though this seems to take an enormous amount of CPU time, more than it should actually). Likewise, there\'s an extremely subtle effect when you drag a scroll thumb that cannot be reproduced by a static image; Mozilla draws this correctly.

However, look at dialog buttons. The default button is blue, as it should be, but it doesn\'t throb. This is a case of Mozilla calling the Appearance Manager just to get a background image. It should, of course, be fixed, and likely will be in the future. Butnot just yet.

All told, though, it\'s a very impressive first effort. If it\'s this good having only been out for a couple of days, I can\'t wait to see what it\'ll be like by 1.0 time.

#25 Re: native widgets are truly native

by mpercy

Wednesday January 16th, 2002 10:56 PM

In that case, it makes you wonder why people say support for non-XP versions of Windows will not be forthcoming. It also makes you wonder how much info about drawing native widgets vs. XUL introspecting or whatever is rumors or simply pulled out of someone's ass. ;)

Were there formal designs done on these features or are developers simply flying by the seat of their pants when they want to do something new? If there are actually design docs somewhere, are they internal only to AOLTW/Netscape? Actual developer documentation (as opposed to end-user documentation) would go a long way to keep rumors, misinformation, speculation from flaring up in the first place...

If there is open documentation covering the XUL/XBL/Theming implementation that is the topic of this series of threads, please proceed beat me with it. ;)

--Micko

#27 Re: native widgets are truly native

by kerz

Wednesday January 16th, 2002 11:52 PM

People keep explaining this to you, so I might as well try. No one is claiming that xul is ANY sort of a rendering engine/layer. XUL is creating the structure of the window. XUL is behind ever single natively drawn widget. As hyatt said in your cut and paste in the forums, the difference is that rather than using css background/border colors, mozilla is querying the OS for those. The xul is all still there, mozilla is just overriding the CSS.

jason

#32 Re: Re: native widgets are truly native

by strauss

Thursday January 17th, 2002 9:31 AM

Yes, XUL is still responsible for the large-scale structure of the window. What you and a few others aren't getting is that in the new regime -- at least on Mac and GNOME -- once you get down to a certain level XUL is out of the picture. It's not true that Mozilla just queries the theme engine for CSS attributes like foreground and border color. Instead, it calls the OS native widget rendering routines to draw the widget in its current state, rather than using XUL to render the widget from an HTML-like representation. I gave specific examples of the native OS widget rendering calls being used on both GNOME and MacOS. Did you look at the code? It's in nsNativeThemeMac.cpp and nsNativeThemeGTK.cpp.

As I noted, the Windows code is not as easy to read as the MacOS and GNOME code due to its indirection through an undescribed DLL. It's possible that the native code on Windows does work in the "semi-native" way, simply querying for CSS attributes and still calling out to HTML-like XUL versions of the widgets for rendering. If so, that would mean the feature was implemented differently on different platforms. I tend to doubt that, and the inconsistency would be a problem in itself if it were true, but I can't rule out the possibility based on what I see in nsNativeThemeWin.cpp.

Lee Strauss

#34 This is what we have been trying to tell you

by sab39

Thursday January 17th, 2002 9:41 AM

It seems like you've finally grasped what people have been saying.

YES, it gets the OS to draw the widgets. This is necessary, because many themes simply can't be described in terms of border and background colors. How would you use CSS properties to describe one of Aqua's candy-shaped bubble-buttons?

XUL has *always* been out of the picture once you get to a low enough level. XUL used existing CSS border and background properties to render things before. Now it uses a new CSS property whose *meaning* is "render this as an OS native widget".

I'm glad you finally seem to be grasping what everyone has been telling you for days.

Stuart.

#33 "Native" widgets

by sab39

Thursday January 17th, 2002 9:36 AM

Okay, let me see if I can explain this - it's really not that hard to understand.

XUL is used to describe the structure of the UI. It specifies things like "put a button here, a toolbar here, a menu here with these items in it".

CSS is layered on top of the XUL describing how to render these widgets. Usually up to now this has been done by specifying background colors, border styles etc to match the known styles of OS widgets. The new addition is a "-moz-appearance" CSS style which tells mozilla to actually *ask* the OS what the widgets should look like, rather than specifying colors and styles that *we think* they look like.

The implementation of the "ask the OS what they should look like" step is platform-specific. As you say, on GTK it appears to be done by actually creating a GTK widget and seeing what it looks like. On the Mac the appearance manager is used. On Windows XP, there is a "theme DLL" of some kind which is asked about what the rendering should look like.

XUL has never been a rendering layer; the rendering layer was a combination of CSS and Gecko (which knows how to draw CSS). This is still the case, but Gecko has now been extended to know how to ask the OS to draw a native widget where appropriate.

These are both "true native widgets" AND "xul widgets". The two have never been mutually exclusive. Anyone who said "we can't make them really native" in the past actually meant "we don't know how to". It took a brainwave from a talented engineer to figure out how to do this, and it's now being done.

The implementation stragegy, as I understand it, is actually very different on windows, since windows XP provides this "theme DLL" that is being used here. Thus on Windows we are currently *not* actually asking the OS to create a widget, but rather *just* asking it to draw something that looks like one. This is why the windows code is not trivially portable to older windows versions.

However, there is no reason in principle why the GTK strategy of actually creatingg a widget shouldn't later be implemented for older windows versions too. So far it seems like nobody is interested in using resources to do this. But that doesn't rule out it happening later.

Stuart.

#35 Re: "Native" widgets

by strauss

Thursday January 17th, 2002 10:02 AM

I think it's pretty cool that you can simultaneously acknowledge that I've been right all along and still insist that I am horribly mistaken in some way you can't quite put your finger on. It shows real creativity.

#38 GTK really?

by sab39

Thursday January 17th, 2002 11:08 AM

Actually, I think the only think that you're horribly mistaken about is the fact that you're actually disagreeing with anyone.

My explanation is exactly the same as the one Asa offered, and that numerous other people have given. It can't possibly be any different because that (and reading the bugs and the patches) is my only source of information! I'm no more a "project insider" than you are.

So the only thing I don't understand is, since you actually do seem to more-or-less understand what's going on, why you insist that Asa and every other person who's tried to explain this to you has been somehow lying or mistaken, and yet when I say the same thing I'm "acknowledging that you've been right all along".

(Btw, I did notice that you immediately resorted to namecalling when faced with substantive facts that you couldn't disagree with. If you're really doing more than trolling, you might want to avoid that because it makes it look like you are)

Stuart.

#52 In strauss’s defense

by lucx

Thursday January 17th, 2002 7:33 PM

In strauss’s defense, Asa and sab39 keep harping on the fact that the XUL is being styled. Never did they CLEARLY distinguish whether the OS is drawing the widget (truly native) or whether it is, say, sending some bitmap to Mozilla and saying “here what it should look like, go style it yourself”.

We’ve established that the widgets *look* native, but it hasn’t been discussed whether they *act* native. For example in Mac OS X, since they are drawn by the OS, I’m assuming that a disabled button would be semi-transparent, no?

#54 Re: In strauss's defense

by sab39

Thursday January 17th, 2002 9:29 PM

I can't speak for Asa, and as I point out in other comments, I'm pretty much an outsider myself so I can only go on what I've read from other people, like Asa, who do know what they're talking about. But here's my take on this question:

Fundamentally, it *doesn't matter*. It's an implementation detail. The spec for the new CSS appearance attribute specifies "this should look like a button" or "this should look like a textbox", and whether this is accomplished by getting the OS to "tell us what it should look like" and then using that, or by getting the OS to actually create a widget directly on the screen for rendering, is really an insignificant detail. From the information I have now (which could well be wrong) my best guess is that, in fact, the answer to the question is different on different platforms (closer to the former on windows, to the latter on GTK, mac somewhere in between).

Whether they "act native" is actually a very good question, and one that so far I haven't seen an answer to anywhere. I'm not talking about things like whether a disabled button is semi-transparent - that's still part of the "look". But for example, whether click-and-drag or click-release-click are both valid selection mechanisms for a dropdown (select rows=1) control or for a context menu is an OS-dependent behavior.

So far it's not clear to me whether this pseudo-native theming has any bearing on that kind of behavior. My guess would be that it doesn't, and that the theme changes, however much "native" code they use, still interpret events much the same way as they did when they were pure XUL/CSS. But I'm not sure, and until I see a linux build with these features turned on, I'm not inclined to pass of my speculation as anything but speculation. Perhaps Asa or another mozillan might comment on this issue?

Stuart.

#58 GTK: Native rendering, not native widget

by adsmith

Friday January 18th, 2002 5:14 AM

Well, under GTK it looks to me like it's rendering the button using GTK calls without actually creating a GTK button widget. For example, look at moz_gtk_button_paint http://lxr.mozilla.org/mozilla/source/gfx/src/gtk/gtkdrawing.c#62 and in particular the calls to gtk_paint_box that pass in NULL for the widget pointer. Unfortunately, the online API docs http://developer.gnome.org/doc/API/gtk/gtk-styles.html#GTK-PAINT-BOX for GTK are a little.... errr.... sparse, so I can't be sure.

Therefore, I would agree with you that the widgets will process events according to the XUL model, rather than the native model.

#61 Re: In strauss’s defense

by strauss

Friday January 18th, 2002 7:33 AM

Thanks for your note. There are two important changes that I've been discussing.

One is a change in argument. For the last few years, the big argument against native widgets has been that there were supposedly important CSS attributes that were difficult or impossible to apply to native widgets. If you look at the CSS specs, though, it doesn't appear that any of these are mandatory attributes for form controls, and in fact it appears that CSS3 actually requires the use of system default appearances for form controls, as one would expect given the importance of platform standards in user interface design. I've been arguing this issue without getting much of anywhere since 2000, but suddenly, without any public discussion, the Mozilla project as a matter of policy has turned around and decided that in fact the extra CSS attributes are not important, while platform default appearances are. For people who follow CSS and related issues I think it's important to note how this argument wound up coming out, rather than sweeping the issue under the carpet as an embarassing about-face.

The other change is technical, although it also has significant consequences for the user. There has been a fundamental architectural shift in the XUL widget model. The previous model was that widgets were described in an HTML-like form stored in user-selected repositories that allowed for a variable interface. At runtime, when a widget was created, the XUL layer would go to the user-selected file, pull out the variable HTML-like representation of the widget, and render the widget from that representation. Now, at least when using native widgets, the HTML-like representations in the user-selectable files are ignored in favor of native OS widget-drawing calls. This is a basic architectural shift in XUL, and again it's something that is important to note for people who follow XUL, as well as people who follow the features of theming and skinning of which so much has been made by Mozilla advocates. The scope of theming and skinning is now considerably reduced, given that most users prefer the platform standard appearance.

My attempts to point out these two important changes have been met by the usual chorus of personal attacks against me, and by vague claims that I am committing some error which somehow cannot be pinpointed. II don't think it bodes well for the project that the level of argument continues to be so low.

Lee Strauss

#62 please explain to me

by niner

Friday January 18th, 2002 8:26 AM

> The scope of theming and skinning is now considerably reduced

but how?? It takes a special CSS attribute in the theme to switch from normal behaviour to plattform standard widget drawing while the existing possibilities are still 100% the same so how it the scope considerably reduced? Sorry I can't see any reduction here, just an extension, an additional CSS property that allows the theme to use OS standards for laying out the widgets.

can you explain this to me?

#63 Your arguments

by sab39

Friday January 18th, 2002 9:13 AM

Your first argument is valid, but presupposes that there is somehow a single unified voice that represents "mozilla's opinion". There have *always* been different opinions about this, and there always will be. Some people made the "CSS properties" argument, others said that it was technically difficult to implement, others (such as yourself) said it should be done regardless.

What has happened here is the fact that, as always in an open source project, he who writes the code makes the rules. A particular talented hacker who either believed from the start that this should happen, or was convinced of that argument by someone else, figured out how to implement it and went ahead and did so. All that's happened is a minor shift in whose opinion is most prevalent in the project - not some sudden, dramatic shift of a single, unified "mozilla.org opinion".

This is a very important point which is often missed by critics of open source projects. Unlike within a corporate structure, decisions are NOT "handed down from on high" but rather evolve over time based on the decisions of individuals who are writing the code. Some of those individuals are influenced by their employers, but even then they don't give up their right to their own opinions; they can always use their free time to implement things their own way if they want.

So instead of "the big argument against native widgets" that you describe, there were in fact hundreds of people who all had their own reasons for not personally choosing to work on native widgets. Some of them, even most, may have used a flawed argument about CSS properties. Others may have simply known that they personally didn't have the skills to do the work, or any number of other reasons. But in an open source project, as you've discovered, you can't simply say "somebody should do this" and expect it to happen.

And instead of a big sudden dramatic "position shift" as you describe, what happened was one person produced an actual implementation - that is, decided that the "somebody" should be *himself* - and impressed a bunch of other people enough with what he had achieved that his work was checked in, and is now being worked on by other people too. If, instead of "arguing this issue since 2000", *you* had been the one to actually go ahead and implement it, as Hyatt did now, and done it with as much elegance and flexibility, this change would almost certainly have happened in 2000 instead.

Your second argument has already been addressed but I'll do so again, just in case you missed it. It is the *theme* that gives the CSS declaration that says "render this as native". In fact, the modern skin continues to use the traditional, non-native widget style. So this gives theme creators the power to use native widgets if they want to, without taking away any options they already had.

Stuart.

#84 Re: Your arguments

by strauss

Saturday January 19th, 2002 2:24 PM

Thank you for your polite response.

I do not agree with your voluntary-contribution model of how open source projects are architected. In this case the architectural change was made not by someone who simply came along and decided to do it, but by the person who all along had been the primary technical owner of XUL. Had it been done by anyone else, or without that person's agreement, the code would have been rejected. Once architectural policy had been established and put into design documentation, conflicting code from outside the in-group would not have been accepted. We could of course argue the hypotheticals here, but the fact is that the architectural change was made by the long-established owner of the feature.

As for the reduced scope of theming and skinning given native widgets, my assertion was not that theme creators had any reduced technical capabilities now, but that users showed a marked preference for platform standards, which would make themes or skins that did not respect platform standards irrelevant. Creating good widget sets is a phenomenally difficult task which could easily take a small team of designers two or three years of full time work. Since no one is committing that kind of resources, there is not going to be any real-world competition for the native widget sets from Microsoft and Apple. Themes and skins look even more toy-like and less ready for prime time once they are competing with the native widgets. We can see the marked user preference in the effusive and nearly unanimous user comments about native widgets here and on the newsgroups in the last month. Since few users will use it, the importance of the theme and skin features is much less than it was.

Lee Strauss

#86 Native widgets?

by pirat

Saturday January 19th, 2002 5:06 PM

Hmm, if I understand it correctly use of this special CSS attribute only force XUL widgets to LOOK like native, not behave. In that case your second paragraph is irrelevant. (And I HATE native widgets ;-)

#87 Re: Re: Your arguments

by asa

Saturday January 19th, 2002 8:30 PM

This is not the architectural "change" that you keep trying to make it out to be. This is an addition to existing functionality, not a change to existing functionality. There was a time when we didn't have -moz-border-radius and so we couldn't specify curved boorders in CSS. Then the Mozilla Module Owner (who is specifically tasked as the architectural lead for that module) Dave Hyatt, implemented this mozilla addition to CSS and it gave theme developers a great tool in CSS for making round buttons and whatnot. Modern theme uses this extensively. Border colors was a similar great addition that gives me the ability to specify multiple borders of different colors without having to use an additional XUL box or an image.

This probably doesn't have the negative impact on theme development that you speculate either. It's one more tool, like -moz-border-radius, that gives theme developers the ability to specify that some parts of their theme should pick up a native style, and in the case of OSes that have themes of their own, to pick up the changing OS theme. If anything, I suspect this additional feature will further encourage theme developers to experiment with making specific parts of the browser "better" than native while not having to spend time getting all the other parts as good as native.

I also dispute your assertion that users prefered a native theme. Classic is a darned good match for windows 95-NT users and the majority of people I've seen comment on the two default themes preferred Modern (not me, I've always been in the minority and use classic almost exclusively). I'll give you Mac users on this one but they are a minority of current Mozilla and Mozilla-based browsers users. There are definitely oportunities to do it better than the OS and I think that Microsoft's current shipping WMP theme demonstrates that even they think non-standard pieces of UI for 'flavor' are what the user wants. Another example of this is what the IE 6 sidebar media player looks like compared to the rest of IE and the rest of my win2K apps. MS is not the best example of quality UI but I think my point holds that it doesn't all have to look and feel the same.

--Asa

#88 Re: Re: Your Arguments

by SmileyBen

Sunday January 20th, 2002 6:54 AM

I think the main reason that you are hearing so many people enthusing about native-like widgets is that most people realise this is a new *choice*. The people that want native-like widgets now get them (and say thank you to Hyatt for it), whereas those that prefer Mozilla widgets realise that this doesn't really affect them. You'd hardly expect people to start complaining that a new and exciting possibility is available, which is probably why people find Strauss' opinion on the matter somewhat bizarre, to say the least...

#106 voluntary-contribution model

by SubtleRebel

Tuesday January 22nd, 2002 6:53 AM

What is your basis for claiming that this feature would have been rejected if someone else had implemented it?

If you know of instances where people have written clean code for a new Mozilla feature, but were not allowed to check it in, I would be interested in hearing the details.

#110 Re: voluntary-contribution model

by strauss

Tuesday January 22nd, 2002 10:00 AM

Why do I say that code for a new feature that went against documented Mozilla architectural decisions would have been rejected if it were from someone other than the in-group that owns the feature area? Is that the question?

#111 Re: voluntary-contribution model

by sab39

Tuesday January 22nd, 2002 10:18 AM

I think you are over-stating two different things here.

First, the degree to which this "went against documented Mozilla architectural decisions". The documented decision was to use XUL and an extended form of CSS to create widgets; we still do that. The CSS we used already had mozilla-specific extensions such as display:-moz-box and -moz-border-radius. The only change was to support a new CSS property that caused a specific new rendering behavior. It's probably true to say that code to rip out XUL and CSS and use native widgets *instead* would indeed have been rejected (probably even if it came from hyatt, for that matter).

But this code doesn't go against anything that came before - it's just the logical extension of it. There have been bugs to do this for ages: see http://bugzilla.mozilla.org/show_bug.cgi?id=39375 opened in May 2000, and the subsequent discussion which indicated that the eventual goal was something very similar to what we ended up with. And Hyatt wasn't involved in that bug at all. The only reason it didn't happen sooner is that nobody ever worked on that bug.

The second thing that I think you are over-stating is the extent to which contributions would be rejected by mozilla.org if they were written. I only know of one such instance, and the reason for rejection was that the patch wasn't generalized enough; it was decided (reasonably enough) that a major feature should be done in an elegant and clean way, rather than hacked in. If the submitted code was elegant and clean like this code is, I feel perfectly confident in my position that it would have been accepted in an instant. The only advantage Hyatt has in this area is knowing the code inside out, so he could produce the patch much more easily than anyone else. That doesn't mean he's the only person from whom code would be accepted.

Stuart.

#125 Re: Re: voluntary-contribution model

by SubtleRebel

Tuesday January 22nd, 2002 10:57 PM

Well stated Stuart.

I'd also to say that I would very much hopeand expect that "code to rip out XUL and CSS and use native widgets *instead* would indeed have been rejected." I can not think of any justification for Mozilla to accept "patches" that remove existing functioning features. In cases where a feature has the potential for causing problems, it may reasonably be decided that that feature default to being off, but not removed.

#124 Straight Talk

by SubtleRebel

Tuesday January 22nd, 2002 10:41 PM

The short answer is "No, that was not the question. Will you please answer the question that I asked?"

Now for the long answer...

Although my question is very clearly stated in my previous post, I will quote it for you again here:

"What is your basis for claiming that this feature would have been rejected if someone else had implemented it?"

It should be obvious, even to you, that this is not the same as your misguided attempt to rephrase my question as the following:

"Why do I say that code for a new feature that went against documented Mozilla architectural decisions would have been rejected if it were from someone other than the in-group that owns the feature area?"

First of all, you were not talking about "code for a new feature that went against documented Mozilla architectural decisions." You were talking about the implementation of code that enables themes to use native looking widgets. The feature in question does not go against any documented Mozilla architectural decisions.

Why is that you always try to change what other people are saying instead of just responding to what they actually say? (I'll make this one easier for you by making it multiple choice)

A) Is it because you know that many of your positions are indefensible when confronted with truth so you try to redefine opposing positions? B) Are you just trying to confuse things because you take some kind of perverse pleasure out of frustrating and offending other people? C) Are your reading comprehension skills so bad that you honestly do not understand concepts and questions presented in plain straightforward English? D) All of the above

#75 Re: Re: In strauss?s defense

by roc

Friday January 18th, 2002 8:00 PM

> the Mozilla project as a matter of policy has turned around > and decided that in fact the extra CSS attributes are not > important, while platform default appearances are. No, some people decided that the *option* of apply platform default appearances would be worth having. That's great!

Whether or not to apply platform default appearances is ultimately going to be in the hands of users. And that's a good thing. I wouldn't be surprised if a majority of users end up preferring platform default appearances in Mozilla chrome but fully CSS-styleable appearances in Web content, the way Web site designs expect it to be.

#68 Re: native widgets are truly native

by locka

Friday January 18th, 2002 11:16 AM

Drawing an XP widget in the style of a native widget does not make it a native widget. They are still XP widgets and Mozilla is still handling the click behaviour and so forth. Mozilla used to have genuine native widgets (i.e. proper natively managed buttons, checkboxes etc.) but they were next to impossible to control with the finegrain precision that was needed to make Mozilla conform to CSS and the like.

#28 call me old fashioned, but..

by ed_welch

Thursday January 17th, 2002 6:58 AM

I don\\\\\\\'t really care what theme Mozilla has, or if it looks different than my other apps. I would much prefer to see more useful features implemented (like CSS2, for example). Anyway those stupid WinXP fade-in menus just make it slower and more distracting to the eye... My 2 (Euro) cents worth ;)

#29 nice

by wvw

Thursday January 17th, 2002 8:49 AM

That's nice. I like it a lot, the theming. Great work! Only the html-rendering doesn't use it. Pity.

#67 Proof that these are not native widgets

by hixie

Friday January 18th, 2002 10:15 AM

that's being fixed (if you see people talking about "XBL Form Controls" it's this.) Let's hope it makes 1.0; if it doesn't it should make 1.1 or 1.2.

#37 Still waiting for view source.

by tuttle

Thursday January 17th, 2002 10:52 AM

I find it hard to believe this could be the last milestone before 1.0 .

A fully functional view source has not landed yet. This is a must for any web developers to debug they're web applications. While I belive work is underway, I haven't seen many progress updates in this direction lately. Any idea on how many weeks away this will take to correct?

<A href="http://bugzilla.mozilla.org/show_bug.cgi?id=55583">bug 55583</A> <A href="http://bugzilla.mozilla.org/show_bug.cgi?id=40867">bug 40867</A>

#44 Re: Still waiting for view source.

by bzbarsky

Thursday January 17th, 2002 2:35 PM

I'm going to try to fix it this weekend... Just do a dirty hack around the missing APIs.

#59 wohoo :)

by niner

Friday January 18th, 2002 5:16 AM

Thank you thank you :) Think this will make life much easier for many people :)

for the first comment: I think this is not the last Milestone before 1.0. There's still a 0.9.9 in between and maybe more? Even if Mozilla is as great as it is now, they shouldn't rush now. A few weeks sooner or later won't make much difference now but can help a lot to make the best 1.0 release such a large project has ever seen...

#74 re: wohoo

by bzbarsky

Friday January 18th, 2002 7:10 PM

Don't get your hopes up.... I may or may not be able to do an end run around APIs here... :)

#78 no problem...

by niner

Saturday January 19th, 2002 5:29 AM

then just thanks for trying, I keep my fingers crossed ;)

#46 Re: Still waiting for view source.

by xerxes

Thursday January 17th, 2002 3:12 PM

I agree, until the view source is straightened out I will be forced to continue using IE for web developement.

#70 Re: Still waiting for view source.

by johnlar

Friday January 18th, 2002 11:32 AM

I'm curius? what view source features are your missing? I can search the text, and it colors the tags appropriatly. What does IE do that mozilla doesn't?

#73 Re: Re: Still waiting for view source.

by AlexBishop

Friday January 18th, 2002 12:23 PM

Currently 'View Source' fetches the page from the network rather than the cache. This is fine normally but can cause problems with dynamically-generated pages.

Alex

#41 Themes are nice "pretty" features but ...

by baffoni

Thursday January 17th, 2002 2:01 PM

... I would really like to see closure on some old bugs that have been (IMHO of course) the only MAJOR deficits to general use. Such as the added <pre> tags on pastes (bug 98572), or opening an attachment changes it's name (bug 95175), or not seeing all attachments in an email (!) (bug 95619). And no, it is not lost on me that these issues are only email related (to me it is a required feature for general use), but I really would like to see some of these old bugs resolved before they bring in new ones (on features that aren't - IMHO - barriers to general use).

#49 Re: Themes are nice "pretty" features but ...

by fuzzygorilla

Thursday January 17th, 2002 5:52 PM

The collection of developers working on Mail/News is different from the collection of developers who are working on themes. This means that the work on nice "pretty" features is not delaying the closure of "some old bugs". The issue for Mail/News is that <b>as previously announced</b> http://www.mozillazine.org/articles/article2079.html the Mail/News group has been working on performance and footprint for 0.9.7 and 0.9.8 rather than bugs. During the 0.9.0 and 1.0.0 periods more attention will be paid to stabilizing the APIs and fixing the outstanding "deficits to general use".

#80 Re: Themes are nice "pretty" features but ...

by baffoni

Saturday January 19th, 2002 10:42 AM

This is true, but the document says they will still work on issues that block the mail/news from general use,easy to fix, and for dataloss. My premise is that all bugs I cited are general-use blockers (and two of them have dataloss keywords) but there has been very little action with them lately. In the case of the not seeing all atachments, one of the devs thinks it could be solved by opening a different kind of window (mail window rather than view source) - I should hope that as fixes go, that is a fairly minor one.

#100 well, at least you recognize

by pbreit

Monday January 21st, 2002 5:13 PM

well, at least you recognize that the inclusion of mail/news, which should never have been part of a "browser", are single-handedly dealying the release of mozilla.

#127 why can't you recognize. . .

by SubtleRebel

Tuesday January 22nd, 2002 11:29 PM

Why do you continue to bitch about the inclusion of mail/news in Mozilla?

Myself and others have gone into depth previously in these forums showing you that, from day one, Mozilla was a project to develop a suite including browser, HTML editor, mail, and news.

It has also been pointed out on numerous occassions (as fuzzygorilla did in his post directly above yours in this thread http://mozillazine.org/talkback.html?article=2127&message=49#49 ) that work on mail/news bugs rarely, if ever, delay the development of the browser.

If you just want a browser with the mail/news client and other extras that many other people want, then that is fine.

If you want to speed up the development of the browser, then contribute constructively to the development.

If you want to continue to try to blame the mail/news client for single-handedly delaying the release of Mozilla 1.0, then go right and do so, but just not where we can read it. Your blame is misplaced; reiterating it here does not do anyone any good.

If you want to keep harping about the fact that the mail/news client is part of Mozilla, then please don't. It is a moot point. Mozilla has always and will always include a mail/news client. Your complaining about it is just a waste of your time, a waste of bandwidth, and a waste of time for anyone who has the misfortune of reading your post about it.

#42 stability (and talk back)

by starless

Thursday January 17th, 2002 2:03 PM

In addition to 0.9.7 crashing a lot on my Linux box I find for this build that talkback isn't usually launched when it crashes. (About 1 in 5 crashes result in talkback sending the error report in) So maybe the developers don't know how bad 0.9.7 really is??

FWIW the error message I got on the screen from the last crash said: INTERNAL ERROR on Browser End: Exec of "java_vm" failed: 2 < System error?:: No such file or directory Gdk-ERROR **: Fatal IO error 9 (Bad file descriptor) on X server :0.0. INTERNAL ERROR on Browser End: Could not read ack from browser System error?:: Resource temporarily unavailable

#50 Re: stability (and talk back)

by fuzzygorilla

Thursday January 17th, 2002 6:03 PM

Oh, well, that is because of the new feature that was added to the Mozilla talkback builds that queries Bugzilla before trying to submit a new error report. You see, the open bug relating to the issue described in your submission is bug 112434 http://bugzilla.mozilla.org/show_bug.cgi?id=112434 and so Mozilla did not send anything. But seriously folks, talkback builds send stack traces. If Mozilla did not crash in such a way as to trigger a stack trace then you need to try to submit the bug yourself using Bugzilla. http://www.mozilla.org/quality/help/bugzilla-helper.html

#43 Themes are nice "pretty" features but ...

by baffoni

Thursday January 17th, 2002 2:12 PM

... I would really like to see closure on some old bugs that have been (IMHO of course) the only MAJOR deficits to general use. Such as the added <pre> tags on pastes (bug 98572), or opening an attachment changes it's name (bug 95175), or not seeing all attachments in an email (!) (bug 95619). And no, it is not lost on me that these issues are only email related (to me it is a required feature for general use), but I really would like to see some of these old bugs resolved before they bring in new ones (on features that aren't - IMHO - barriers to general use).

#47 Wrong Version Number

by xerxes

Thursday January 17th, 2002 3:59 PM

I wonder if the version number will be fixed before the release of 1.0? Currently, through JavaScript Mozilla identifies it self as Netscape version 5.0. It's been like this for ages and it's kind of bizarre if you ask me.

#48 Wrong Version Number

by xerxes

Thursday January 17th, 2002 4:01 PM

I wonder if the version number will be fixed before the release of 1.0? Currently, through JavaScript Mozilla identifies it self as Netscape version 5.0. It's been like this for ages and it's kind of bizarre if you ask me.

#60 Re: Wrong Version Number

by Chucker23N

Friday January 18th, 2002 5:30 AM

It's supposed to be like that. Otherwise, many bad html pages just checking for the major version number will recognize Mozilla as "Netscape 1.0" or another browser from '95 or earlier.

#90 The version number

by StigN

Sunday January 20th, 2002 12:17 PM

Why doesn't we just call it Mozilla 5.0 ? This will cause much less confusion. I guess this question must have been discussed allready, so can somebody give me a reason it has been chosen the version-number 1.0 ? Generally the Mozilla browser is already known as Mozilla 5 pretty much everywere. And how are we going to explain the userAgent string says "Mozilla/5.0..." ?

#97 The version number

by zreo2

Monday January 21st, 2002 8:00 AM

I guess it was a bit silly calling it version 4.1 two years ago when you think of how good it was. "Nearly started" =)

#98 Re: The version number

by jcf76

Monday January 21st, 2002 11:16 AM

The problem is that there are several things called "Mozilla". There's Mozilla-the-Browser which is coming up on its 1.0 release in a couple months. The "Mozilla" in the UA string used to denote which version of Netscape was in use; now it's just become a kind of generic way of saying "This is an nth generation browser".

So in that case, Mozilla-the-browser may be nearing 1.0, but it really is a fifth-generation browser (IE still identifies itself as fourth-generation, which given its level of standards support may not be a bad idea).

It can be a little confusing, but if you think about it that way, tnds to make more sense. Now, whether they /meant/ it to be that way is another story ;)

#113 Version Number vs. Gecko DateStamp?

by eiseli

Tuesday January 22nd, 2002 12:41 PM

Isn't the Gecko Datestamp the best way to see what browser you are using? Of course if you're using a gecko based browser. Galeon, Konqueror, Kameleon, Mozilla, Netscape... That's a lot! And I forgot some, I bet. Next to these, just IE which doesn't have a Gecko time stamp... It would be about time they changed that! ;-)

#129 Re: The version number

by StigN

Wednesday January 23rd, 2002 1:44 PM

Yes I understand the browser version versus the nth browser generation number issue. The point is, most people won\'t. I\'m sure we will se a lot of confusion regardig this.

#55 Radio buttons and checkboxes

by Vec

Friday January 18th, 2002 2:29 AM

Does anyone know if the problematic look of these elements (looking weird when you click on them, until you click on the next one) is ever going to be fixed? Or am I the only one who has this problem. I think that it's the first thing that can dissapoint a first time mozilla user running it on a P4 PC (speed is not an issue). He will stop using mozilla before finding out about the cool features....

#91 Re: Radio buttons and checkboxes

by goodwatast

Sunday January 20th, 2002 4:40 PM

I have that problem too...

Windows 2000, Mozilla 0.9.7

#56 Re: Stability

by flacco

Friday January 18th, 2002 4:05 AM

I've noticed some stability issues with Mozilla on 0.9.7, for that matter. Occasionally the browser just shuts down and I have to restart.

#112 Agreed

by thoffman11

Tuesday January 22nd, 2002 11:51 AM

I've noticed them too. Often times I click a link, and the window and/or entire browser closes.

#117 Re: Agreed

by asa

Tuesday January 22nd, 2002 2:44 PM

What links? Is it consistent on any particular link(s)? Does TalkBack pop up? Are you sending in Talkback reports? What are the TalkBack Incident IDs? Have you reported this to Bugzilla? What is the bug #?

I appreciate general \"it\'s less stable\" or \"it\'s more stable\" comments so don\'t take my questions as discouragement. If you are having specific and reproducible failures, however, it is in your best interest to follow-up a little (sending in talkback takes about 10 seconds, filing a bug takes a few minutes) by providing information that helps us fix the bug.

And if you send in talkback or include that in your bug report (and somehow let me know the incident ID) I\'ll even help see that that bug gets assigned properly.

--Asa

#120 No talkback for me

by CatamountJck

Tuesday January 22nd, 2002 5:42 PM

I don't know about anyone else but when this happens (although not very often in my case) I don't get the talkback dialog as a result. The browser just disappears and I have yet been unable to reproduce it.

#130 No talkback for me

by starless

Wednesday January 23rd, 2002 2:00 PM

> submitted by CatamountJck > I don't know about anyone else but when this happens (although not very often in > my case) I don't get the talkback dialog as a result. The browser just > disappears and I have yet been unable to reproduce it.

Here's a URL where mozilla 0.9.7 crashes for me but with no talkback: www.shamrockin.com/stressmonkey.htm

#131 No talkback for me

by starless

Wednesday January 23rd, 2002 2:45 PM

and here's another URL which always causes a crash in 0.9.7 (Linux) with no talkback:

www.uhero.com/uhma/artist_detail.cfm?ID=290

#132 No talkback for me

by starless

Wednesday January 23rd, 2002 3:42 PM

and here's yet another URL which crashes mozilla 0.9.7 without talkback:

www.geddylee.net/cgi-bin/Ultimate.cgi

All 3 sites are apparently music related.

#134 Re: No talkback for me

by asa

Wednesday January 23rd, 2002 4:38 PM

These seem to be pages with Java. Do you have a JRE installed? Which one? What happens if you uninstall or install a JRE (Sun JRE 1.3.1_02 is the one to get I think)

--Asa

#133 Bugzilla

by pirat

Wednesday January 23rd, 2002 4:28 PM

It took me two HOURS to submit my first bug and it was so confusing I did it again later only once when the problem was very important for me... I know there simply isn't nothing better (and free) than bugzilla, but it's probably one of the reasons why so many possible and reasonable bugs are only discussed here and there or even never shown up.

#135 Re: Bugzilla

by asa

Wednesday January 23rd, 2002 9:31 PM

It took me about 20 minutes to file my first bug and that was before the bugzilla helper. What took you 2 hours? What bug was it? Did you use the Helper or the advanced form?

--Asa

#57 Re: Stability

by flacco

Friday January 18th, 2002 4:18 AM

I've noticed some stability issues with Mozilla on 0.9.7, for that matter. Occasionally the browser just shuts down and I have to restart.

#64 Native Widgets

by SmileyBen

Friday January 18th, 2002 9:44 AM

Something that has been totally ignored in this debate, which seems to me pretty much the most important thing is that, as I understand it, native widgets were simply /additional/ work. There are still Mozilla specific widgets in loads of places (it would look ridiculous if the 'Go' and 'Search' buttons in the Modern theme were native widgets), so this isn't dropping Mozilla widgets for natives ones at all - far from it, if they did that they'd set things back months.

And considering this fact, it seems to me that nobody need give any response to Strauss above 'There simply wasn't time to implement an entire other way of selecting widgets'. Strauss is welcome to argue that unity is so important that this should have been a priority (I, and no doubt many others, strongly doubt that), but that seems a rather strange complaint to lay at a pre-released product - we'd hardly moan that a closed source product didn't have our favourite feature a couple of months before the release, only at the time of the release...

#72 Re: Native Widgets

by Tanyel

Friday January 18th, 2002 12:07 PM

Maybe it would be good to alert people of the problems now so people will not moan when the product is declared to be ready.

#65 Native Widgets

by SmileyBen

Friday January 18th, 2002 9:45 AM

Something that has been totally ignored in this debate, which seems to me pretty much the most important thing is that, as I understand it, native widgets were simply /additional/ work. There are still Mozilla specific widgets in loads of places (it would look ridiculous if the 'Go' and 'Search' buttons in the Modern theme were native widgets), so this isn't dropping Mozilla widgets for natives ones at all - far from it, if they did that they'd set things back months.

And considering this fact, it seems to me that nobody need give any response to Strauss above 'There simply wasn't time to implement an entire other way of selecting widgets'. Strauss is welcome to argue that unity is so important that this should have been a priority (I, and no doubt many others, strongly doubt that), but that seems a rather strange complaint to lay at a pre-released product - we'd hardly moan that a closed source product didn't have our favourite feature a couple of months before the release, only at the time of the release...

#66 Proof that these are not native widgets

by hixie

Friday January 18th, 2002 10:12 AM

These widgets are not true native widgets.

They look like native widgets because they are painted by the theme manager in the OS or windowing system (and yes, they are implemented differently on each platform).

But they are not truly native widgets. On Windows, for instance, there is no window handle associated with the native-looking buttons. And they still use XUL, XBL and CSS in addition to the new theme stuff.

If they change to match the active theme even when the theme is changed, that is simply because the OS is notifying Mozilla that the theme has changed, and Mozilla is repainting everything.

See: http://www.damowmow.com/mozilla/demos/appearance/

#69 Re: Proof that these are not native widgets

by johnlar

Friday January 18th, 2002 11:25 AM

I'm confused, is the paragraph really supposed to look like a button and the list supposed to look like checkboxes. Because they don't.??

#71 For those of us without recent builds...

by sab39

Friday January 18th, 2002 11:58 AM

Could somebody post a screenshot of that page taken from a recent nightly in WinXP or OSX? :)

#76 Slow Windows

by exotrip

Friday January 18th, 2002 11:50 PM

I have heard that Mozilla 0.9.8 will be released as Netscape 6.3. This can not happen. New Windows are so slow, people will not stand for it. This bug is very serious and I can't understand why it is still there. Bug #?

#77 Re: Slow Windows

by jonasj

Saturday January 19th, 2002 5:22 AM

Netscape 6.3? Where did you hear that?

New window perf: http://bugzilla.mozilla.org/show_bug.cgi?id=49141

#81 Re: Slow Windows

by fuzzygorilla

Saturday January 19th, 2002 11:06 AM

Saying things like "people will not stand for it" is silly. People will stand in lines for hours to buy tickets for the premiere of a movie. People have already "stood for" even slower new window speeds in Netscape 6.0, 6.01, 6.1, and 6.2. The time required to open a new window has been going down. And it will continue to get better. Yes, it is true, the speed of new window and other operations is serious. And the Mozilla and Netscape teams are treating it seriously. The speed is being monitored on a daily basis and when changes to the source code cause the speed to decrease, the changes are carefully evaluated. and have been backed out in some cases. The reason why it is still there is simple. It is not an easy problem. The developers profile the code and determine where the problems or bootlenecks are and then try to see how to remove the bootleneck or improve the efficiency of the algorithms.

#79 AOL in talks to buy RedHat

by thomanski

Saturday January 19th, 2002 5:43 AM

http://www.washingtonpost.com/wp-dyn/articles/A5064-2002Jan18.html

Thrilling, don't you think?

#82 Re: AOL in talks to buy RedHat

by Kovu

Saturday January 19th, 2002 12:11 PM

Very. I think I will be the happiest camper on the planet if this happens. AOL can push Linux like no other company could (except Microsoft).

James

#83 Argh...

by masi

Saturday January 19th, 2002 1:44 PM

I fear for the worst. Don't give AOL anything! If the own your desktop the will own you even more then Microsoft.

#102 Linux proprietary internet

by PaulB

Monday January 21st, 2002 8:39 PM

From the article it was unclear if AOL, if it bought Red Hat, wanted to make it a propritary OS for AOL. I hope this doesn't lead to the situation where parts of the Web require Linux to fully function. It is bad enough that some sites require Windows to fully function. I would like to see AOL move away from the propritary MS software, but I hope they do not substitute Linux as another propritary OS. My wish is that the web remain as platform independent as possible. I want to choose my own OS (OS X) not the OS someone else has set as the default OS for the web to fully function.

BTW I wonder if AOL looked at OS X to for an operating System. Its UNIX just like LINUX with a much improved and easy to use interface? I am sure they don't want to purchase new hardware, but is Linux ready for prie time on the the "Home" computer. It may be ready for AOL servers, but if the end users OS is substituted with Lunux to use AOL, unless AOL write and "AQUA" interface to Linux as Apple did for BSD than AOLs ease of use may take a serious hit.

Thias is good news. There are serious questions, namely protecting the internet so that it can be accessed fully with any computer, OS and browser. Up to now I have felt AOL was doing an adequate, though not perfect, job at protecting the internet. Now I don't know if AOL will simply attempt to set up another proprietary OS on the internet. Will AOLs adoption of Linux enable Linux to gravitate to the status of an OS required to fully experience certian sites on the Internet? I am not sure, but I hope not.

#104 Argh...2

by zreo2

Tuesday January 22nd, 2002 12:53 AM

I Agree. AOL complains on how microsoft implements other products into their environment, like IE. But are they better themselves ? No, not at all. Since AOL bought Netscape you have to be very observant when you install Netscape. All those icons, all those extra programs that you dont want... The best part is "be a member of AOL or sign up for dial up etc" Very usefull for us non-americans. Even Microsoft wouldnt be that stupid.

#107 not that stupid?

by niner

Tuesday January 22nd, 2002 8:15 AM

If you install Windows you have the same MSN crap on your hard drive and desktop. And if you start IE you go directly to the MSN site, the same if you mistype an URL so how is this better?

And why shouldn't AOL try to use Netscape for advertising? As long as they leave Mozilla untouched I see no problem

#108 Re: Argh...2

by roc

Tuesday January 22nd, 2002 9:06 AM

> But are they better themselves ? No, not at all.

EXCEPT that they give you almost all the source code to Netscape so you can easily build your own Mozilla without any branding, or with your own branding, and with your own hooks into whatever you want.

So until Microsoft open-sources IE, I think AOL is very much better.

#85 Hyatt posted a doc about the theme interface

by hixie

Saturday January 19th, 2002 3:59 PM

Hyatt has posted some documentation about the theme interface.

See: http://www.mozilla.org/projects/xul/theme.html

#92 NIM in Mozilla

by PsychoCS

Sunday January 20th, 2002 6:28 PM

I think that this question was previously addressed somewhere, but I can't find it...

Anyway, I was wondering if it is possible to install the NIM "Buddy List" feature of Netscape 6.x into Mozilla; I just switched from N6.2 and this, along with the lack of Netscape mail server support, is the only thing I really miss. Thanx...

#93 NIM in Mozilla

by PsychoCS

Sunday January 20th, 2002 6:28 PM

I think that this question was previously addressed somewhere, but I can't find it...

Anyway, I was wondering if it is possible to install the NIM "Buddy List" feature of Netscape 6.x into Mozilla; I just switched from N6.2 and this, along with the lack of Netscape mail server support, is the only thing I really miss. Thanx...

#94 My bad

by PsychoCS

Sunday January 20th, 2002 6:30 PM

Oops...sorry about the double post...actually it happened because I reloaded the page and clicked to resend postdata (namely my message). A bug perhaps?

#95 Re: My bad

by WillyWonka

Sunday January 20th, 2002 6:54 PM

Why would it be a bug? You just said you told the computer to resend the data. "Data" means the form, which was the message you just wrote.

#101 ...

by PsychoCS

Monday January 21st, 2002 8:38 PM

True...I became aware of what I did wrong as I pressed OK, but it's misleading in the sense that it takes you back to the forum *without* your post, and as you naturally tell it to reload to see your post, you can accidentally resend the info. That's why I see so many double-posts on MozillaZine...okay, 'bug' was the wrong term to use, especially around here... Anyway, my original question about Netscape Instant Messenger still stands...

#109 It -IS- a bug

by JoeCool

Tuesday January 22nd, 2002 9:11 AM

It's a usability bug. It could also be contstrued slightly as a security bug since the same "feature" makes spamming the board easier. So, understanding how users approach posting on the forum, a little bit of code could easily be written to, upon a new post, attempt to see whether a new post from that user had been submitted in the past 10 minutes, hour, or whatever, and then, if so, compare to see if any of the posts match. If they do, then simply ignore the latest post. Problem solved. It has 1-2 more selects per posting operation that currently is being done, but that's not likely to bring down this site again, I would hope.

Bugs aren't always the computer acting wrongly. They can also help keep the user from messing up and make things easier (yeah, I know this is MS-speak, but computers ARE tools after all).

(Oh, and moz-zine could stand to fix their long-outstanding display of ///////// whenever an apostrophe or quotation mark is used)

#114 easy

by niner

Tuesday January 22nd, 2002 1:09 PM

I've done such thing on our forums. It's easy, just search the database for a posting with same title, author, text and maybe roughly the time before storing it so you see if it's already there. This way you catch the reload and double click on submit button problem.

Would be a nice feature if someone finds the time...

#121 Or handle it like Slashdot with form keys

by tepples

Tuesday January 22nd, 2002 5:47 PM

>just search the database for a posting with same title, author, text

Slow. I'd handle it like Slashcode: Give out a randomly-generated form key when a user clicks Reply, and then make sure that the form key submitted along with the text matches a valid form key in the database. Expire form keys when a comment is submitted or after an hour.

#105 Re: NIM in Mozilla

by shin

Tuesday January 22nd, 2002 2:05 AM

It looks like there is no chrome for NIM in Mozilla, so you cannot make it work. I asked and got that reply. I tried installing anyhow and copied Netscape6.2's chrome, but no luck here either ;) May I suggest you use Trillian for instant messaging ? :)

#119 Re: Re:

by PsychoCS

Tuesday January 22nd, 2002 5:14 PM

Thanks. That's too bad...

As a second question to you guys, is there a way of getting to your Netscape WebMail with Mozilla via IMAP/POP etc. and if so what's the server (this is what I get for momentarily switching to N6 from Moz--it's different)?

BTW I do use Trillian, but the less RAM needed, the better...

#122 Re: Re: Re:

by asa

Tuesday January 22nd, 2002 8:14 PM

>is there a way of getting to your Netscape WebMail with Mozilla via IMAP/POP etc.

No.

--Asa

#123 Re: Re: Re: Re:

by PsychoCS

Tuesday January 22nd, 2002 10:00 PM

There! that's better; a yes or a no. Thanks.

#116 AOL's Netscape sues Microsoft

by xerxes

Tuesday January 22nd, 2002 2:43 PM

It seems AOL has launched a law suit based on Microsoft's business practices during the browser wars.

http://news.com.com/2100-1001-820227.html

#126 Re: Native Widgets

by Tanyel

Tuesday January 22nd, 2002 11:03 PM

Com.com is the most stupid domain name I have seen this year.

#128 Most Stupid domain name of 2001?

by SubtleRebel

Tuesday January 22nd, 2002 11:40 PM

Tanyel, just out of curiousity, what was the winner last year? :)