mozilla.org Branches for 1.0Tuesday April 9th, 2002mozilla.org today cut the MOZILLA_1_0_0_BRANCH for 1.0 to use. Expect to see an RC1 candidate sometime next week in order to see where the builds are as far as stability and usability. Work will continue on the branch up until the final 1.0 release, and beyond for point releases. An updated roadmap will be posted soon reflecting this. The trunk is now open to 1.1 alpha work, on the road to 2.0! Only joking of course! Our "friend" Mike Angelo has already written one of his pathetic articles on MozillaQuest about it, proving once again that just hasn't got a freakin' clue about this whole Mozilla thing! I would put a link to the aforementioned article, but I just can't be bothered! If you want to read his latest batch of rabid rantings, and you could perhaps do with a laugh, well . . . you know you can find it! If . . . you can be bothered! Okay, I admit it.. I just checked out "mozillaquest.org". I was curious. But then I got a big surprise.. the site content was identical to "mozillanews.org". I thought that these two sites were not related! According to nslookup, both "mozillaquest.org" and "mozillanews.org" have the IP address "206.156.254.50". Has somebody hijacked mozillaquest's DNS entry? Oh, the difference is in the .org and .com, looks like he who has mozillanews.org also has mozillaquest.org (not .com). Some people don't seem to realize that by mentioning MQ, esp. here at MZ, that in fact lends to the existence of that silly site. Stop talking about MQ and maybe it'll go away. Out of sight, out of mind, right? Doesn't work - other sites like www.newsforge.com seemingly "blindly" accept any news submissions from Angelo and duly publish them. BTW, I would still contend that a spelling checker isn't an "essential feature" (it would be a nice enhancement to Mozilla and ironically doesn't apply to the core browser component anyway !) and is available in Netscape 6.X (which is the browser Angelo *should* be reviewing, not Mozilla !). Also note that Internet Explorer does NOT have a spelling checker... I think that it is better to state clearly what the problem with the info there is, instead of \"keeping silent\" about it. The article at Newsforge will make many people go there who dont even know that Mozillazine.org exists. Keeping silent wont work ... counter attack with more realistic and relevant info! what happened to MQ? it used to be serious. Fabian Guisset (moz DOM hacker) used to write for them. what cheesed angelo off? is he an ex AOL employee? Good news: NewsForge http://newsforge.com/ reported on the branching. Bad news: They linked http://newsvac.newsforge.com/article.pl?sid=02/04/10/006205 to MozillaQuest. Alex Has anybode tried to contact this guy and explain what Mozilla is all about? He is just embarassing himself and the most tragig part is that they link to his site. He doesn't care. He spreads his misinformation not out of ignorance but out of a desire to discredit the Mozilla project. In short, he's an asshole. http://bugzilla.mozilla.org/show_bug.cgi?id=137260 The benefits of spending a couple of minutes submitting the release news with some cuddly introduction at the start to get people to try it to Newsforge as apart of the release process would far outweigh time spent. Why do Mozilla.org let MozillaQuest get away with peddling this tripe? It's like the KDE development group letting Microsoft PR issue a press release about their new milestone. Mike Angelo's ill-informed bulls**t is at mozillaquest.com not .org! Oh botheration, I've gone and flamin' well linked to it now! Can somebody not sue him... or better yet just DoS him into next week? And can somebody talk to whoever at NewsForge and let them know definitively that MQ has nothing to do with Mozilla? Here's another idea... let him express whatever opinions he wants on his own website. We should all be big enough to tolerate the existence of opinions/writings we disagree with. He has just as much right to make himself look like a jerk as anybody else. maybe it would be worth the effort then to post a qualified article that links back to this and the previous article here? I dont know how popular NF is, so it could lead to a temporary /. ing here, but this would be better than all those people *thinking* that MQ is in some way an official Mozilla site. slashdotted... Quote from the article: "To the Mozilla Organization's and Mozilla Project's credit they almost have a darn nice browser suite." I think that's nice :) i would be a shame if this (http://bugzilla.mozilla.org/show_bug.cgi?id=28028 ) wasnt resolved for moz 1.0. the issue has been kicking around for long enough. it would also be bad to have a netscape owned green lizard in the 1.0 splash screen. apart from this and the fact that back/forward has been removed from image context menus, everything is excellent. i definately put this url in: http://bugzilla.mozilla.org/show_bug.cgi?id=28028 dont know what went wrong... Another thing that should be fixed is the icons. As it now you cant see the difference in the taskbar if it is the browser, composer, the javascript console etc. You can only see this blue thing that looks like a turd (Sorry, but it does). sorry I dont get it - what are really the issues here? As far as I understand some person asked over two years ago whether he can use the images from Mozilla.org and nobody was resolve this issue in th meantime? An estimated 20% of all source code in the tree is made up of some copyright/license text (I never read) so it shouldnt be that hard to add another 2K somewhere ... :) i think its like this: moz have to change their splash screen cos the green lizard is netscape owned. presumably they need to use a red dino, but rights to this dino have legal implications, which presumably are what this bug relates to. so this bug blocks the splash screen issue, and any other imaging issue (icon, about screen etc). of course, i may be wrong. there are people on this forum much more qualified to comment than i am... :-) does this mean that not only a specific picture with a green lizard is netscape owned but the green lizard itself? How can you "own" a green lizard? And what really are the implications for the red one? This is cracy: there are thousands of source code files, hundreds of icons and other parts of the theme which dont pose a problem, and the splash screen or a couple of icons do? I read this MozillaQuest article. It did not make sense to me because for his bug count numbers to be meaningful, one would have to compare them with competing browsers' bug numbers. Mozilla has a longer uptime between crashes than Netscape 4 and this is what I _can_ count. And because Mozilla is open, one can help as well. Please check out the crasher http://bugzilla.mozilla.org/show_bug.cgi?id=131841 At this time all it needs is a nice person to copy the testcase to a secure server. Thank you. What's the history of the rivalry between MozillaQuest and Mozillazine? The're both having the same goal, or not? No they don't have the same goal. Frankly it's hard to see what Mozillaquest's goal is. Mike Angelo (the sole contributor to MQ) is generally clueless about Mozilla and never has a good word to say about it. His articles are always negative, filled with misinformed spin. He also likes to bitch about the number of bugs remaining and that no one in mozilla.org, Netscape or AOL answers his emails (I wonder why). No one in the Mozilla community really cares what he says. OTOH Mozillazine is more like a news magazine for Mozilla & Mozdev developers and is informed and trusted. Generally it is neutral/positive about Mozilla but not in a bum-licky-crawly type way and is not blind to faults that crop up in the release/development process. It also has a talkback forum :) I hardly think so. :) Positive, yes. Neutral, no. I mean this is basically \'the voice of Mozilla\'. (That doesn\'t mean there\'s anything wrong with it - and yes, the talkback / forums balance things. Actually, it also helps that nowadays there really isn\'t too much negative stuff left to say Mozilla at least as a Web browser...) --sam > What\'s the history of the rivalry between > MozillaQuest and Mozillazine? The\'re both > having the same goal, or not? They\'re not. MozillaZine\'s goal is to provide news and advocacy about Mozilla. MozillaQuest\'s goal is to bash Mozilla whenever possible. Mike Angelo is nothing but a troll. None of the complaing about the horrible reporting quality (actually, it\'s near slander with twisted facts) on MozillaQuest. The fact is that the site is successful because it satifies the readers hunger for interesting and up-todate news on Mozilla. It\'s a simple phychological fact that every non-PBS TV station capitalizes on (who really thinks \"Survivor\" is about surviving). Anyhow, someone with PR-sense and the desire to write (grayrest, Holger Metger?) should either put up an official Mozilla page, or mozillaZine needs to put up some more gernerally interesting articles on a more frequent basis. Also, these articles must also be critical in a way that is interesting to outsiders (no: \"DOM inspector misses w3c subrule #15.09.R-34 -who cares). Charge: € 0.02 >Anyhow, someone with PR-sense and the desire to write (grayrest, Holger Metger?) Working on it, but finals are coming. Finals are coming. And my grades need to go up. grayrest #33 Re: We need a Mozill News Site with an Attitude!by Salsaman Wednesday April 10th, 2002 11:07 AM I only look at mozillaquest.com to check the \\\'bug status\\\' in the right hand margin. If there were another site that showed this, I\\\'d never go to mozillaquest.com. #40 Re: Re: We need a Mozill News Site with an Attitudby AlexBishop Wednesday April 10th, 2002 5:41 PM "I only look at mozillaquest.com to check the 'bug status' in the right hand margin. If there were another site that showed this, I'd never go to mozillaquest.com." There is. It's called Bugzilla. ;-) http://bugzilla.mozilla.org/ Alex I also do this regullary for bugs count. PS Bugzilla does not provide the easy and quick way to look at the bugs count. Sorry... and what value do you get from that count? Do you decide whether to download a testing binary or not based on that count? Do you decide whether or not to file your latest bug based on that bug count? Do you make the decision to evangelize standards support or not based on that bug count? Do you decide to release or not release a commercial mozilla-based product based on that bug count? I could understand if he had up to the minute info on a bug you were watching or a catagory of bugs that were important to your mozilla-based product but they're just numbers that you could get, and even more up to date and accurate, with a few bookmarked queries or a quick run of the summary reports at Bugzilla. There really needs to be a comprehensive bugzilla tutorial put up somewhere along with bookmarkable searches of the most commonly needed bug estimates: standards compliance bookmark, overall outstanding bugs, outstanding "real" bugs, or whatever. This needs to be done by someone who works on bugzilla on a regular basis (triager), I can't do it because I don't know enough about querying for various bugs (I can't find dupes anywhere except calendar and only there because I read ALL the bugs for calendar). I use it more to track bugs people link to or bugs with the particular component I'm working on at the moment. Really all it needs to be is the top three or four queries your perform and why you perform them that way followed by a listing of all the features bugzilla provides. I hope someone puts together a nice tutorial. It'd be a great resource for the community. I'm willing to do the editing/adding pictures/adding overview if someone can write just the queries part and I can find a list of all the features somewhere. grayrest What are the standard queries? I am not a Bugzilla wizard or anything, but I'd be willing to figure out the query links for you if I knew what a standard query was. Besides the QA menu link to "Bugs Filed Today" (which every Mozilla user has easy access to) almost every query that I do is different from one day to the next. BTW, the query URL for "Bugs Filed Today" is as follows : <http://bugzilla.mozilla.org/buglist.cgi?changedin=1&chfield=%5BBug+creation%5D&chfieldto=Now&product=Browser&product=MailNews> There is no such thing as a standard query, I just figured there was a set of fairly frequent queries that people would like to know: how many CSS problems, how many html problems, how many bugs, that sort of thing. grayrest Now just patch it for using Keithp\'s font library and all is set :) Then at least 1 (one) application uses the system fonts! I'd like to note that roughly half of the posts so far in this talkback are about "that other site". If you want to discuss that site, go there. I'm sick of hearing about it. New Context Menu sucks!. The most reason I use Netscape Browswer is because "BACK" button is on Every conext pop up no matter where were you at. Now mozilla is switched to IE style. I want my back button. XUL crap was easier before now Its like writing code in C++++++++++++. As I'm typing right now every other world makeing scroll bar on TEXT windows toggling. it will be fun to have in my screen, Mozilla 1.0 running. What are you talking about? The context menu has not changed! The new context menu is only displayed if you have text marked on a page. If no text is selected, there's still back, forth, reload and stop on the context menu. if you bring the menu up over an unlinked image, back/forward are not there. for sites that use transparent spacers as padding for example, the context menus become a pain to use. this is my biggest pet hate about IE, and now its in my fave browser :-( Pah... pages should NEVER EVER use transparent spacers! They should use CSS, which is much better, because it allows relative spacers (e.g. one and a half line heights), that scale together with the font-size of the page, unlike absolute ones (pixels) that always stay the same. In IE I can go backwards hitting the fourth button of my mouse. Not that I like IE, but Mozilla can't get close to this kind of comfort (I'm afraid). If you browse a site that have huge pictures its really annoying to view the picture that viewing again because you're used to Back/Forward context menus. I think even if you're in frames back/forward/stop(basic navigation functions) should be the top Menu items on context menu. I just want to right click and go back to previous page in history. I'm writing a complain bug. Join the club. There are several bugs already posted but apparently Netscape marketing trumps good UI in Moizilla. "Netscape marketing trumps good UI in Mozilla". Not really. There are two schools io thought here and neither is good or bad...you may like one over the other, but that doesn't make one good and the other bad. If I understand the situation concerning popup menus here is what took place. A while back the goals for the Menus and in particular popup menus changed. Netscape and Mozilla had their seperate goals for the menus. In particular Netscape chose to restrict their popup menus to true context sensitive menus. The context (what the mouse is over) determines the menu items in the popup menu. Netscape in pushing for context menus, claims that the design is less than ideal if items are included in the menu that do not relate to the context (although there are a few exceptions). Thus in context sensitive menus, if the mouse is over a picture, it is bad design to include "back" and "forward" in the popup menu. Now Mozilla's design team, understood its popup menus in a broader manner than context sensitive menu. Mozilla could under this model include a variety of menu items in a popup window that did not always correspond to the context (ie what the mouse pointer was over). Over time the popup menus in Mozilla became large with many items. I believe Netscape felt this was not the best way to design the popups. [Before the menue design I found it was often had to click on an item near the top of the popup if you started moving up the list from near the bottom. Often the wrong item ended up being clicked.] In Netscape's viewpoint the popup menus in Mozilla were too long and contained too many items. which could be confusing and lead to clicking the wrong items. Netscape solved this problem by switching to context sensitive menus for the popups. The context determines which items are in the menus. One of the benifits of context sensitive menus for popups is that there are fewer items to choose from in the list. For Netscape one design goal is that menus should contain the fewest items while still retaining the needed funtionality. There is one item missing from the popup menu (if you are following context sensitive guidelines) which concerns url links: when right clicking a link, why is there not option to open in a new tab? If the context is url link, isn't "open in new tab" within the context? I am glad that the popup menus moved to context sensitivity. I no longer end up clicking the wrong items due to the large number of items. I find these menus more efficient. On an aside, there is one feature of the popup menus I find slightly annoying, why does both the right and left mouse button call up the popup menu? Ofter while attempting to select some text or perform some other task with the left mouse button a menu I don't want will popup and I have to dismiss it. [I guess, but I am not sure, that the left button was provided with the "long click" calling a popup is implemented for users with a one button mouse.] The left "long click" function may be an important function for many, but I would vote for a preference check box to turn it off. So there are two schools of thoguht here: one in use, and favoured by Netscape: Context Sensitive popup menus. The other, formerly favoured by Mozilla, not to use context sensitive popups. This is how I understand the situation. (I may have got it wrong. If I understand the situation correctly, I am happy with the UI guidelines for popups.) I do not believe that the issue is divided exactly between Mozilla and Netscape. For example, many Mozilla.org people agreed that the context menus were too long and needed revised; also there were various Netscape people who were not completely happy with what did and did not end up as part of the context menus. Both organizations believe that the primary purpose of the right click popup menus is for access to context sensitive functions. The debate seems to mostly be about which functions should not have been removed from the popup menus, which ones need revised, and which new items should possibly be added. My personal view seems to be very much in the minority. I believe that almost all of the previous functions should have remained available in the popup menu and that there should be a preference panel to allow people to choose which ones are needed and which ones are not. I agree that too many items in the popup menu makes it unwieldy, but different people have different needs. It is not Mozilla's goal to be the most widely used browser; Mozilla's goal is to be the browser that the most widely used browsers are built from. In order to achieve this goal, Mozilla needs to have lots and lots of features available; developers like Netscape, Beonex, Galeon, K-Meleon, etc can then pick and choose which features and options that they want to include or not include in their browsers. Why should Mozilla reduce access to any features? Items were added to the context menu because someone thought it would be handy to have the item there; for me that is enough reason for it to stay there in Mozilla. If Netscape wants to reduce the number of items in their context menu, then they can do so as they see fit. If Mozilla's context menu is too big then context menu items should be configurable via preferences. I realize that a lot of UI people are opposed to an abundance of prefs, especially when those prefs can greatly change the placement of menu items and such, but I much prefer to customize my UI to my specific needs rather than try to conform to using the standard options made available. I for one like the shorter menus - they are easier to navigate and contain most of the functions I use. I would like to see back and forward re-added in places, and I personally like MPT's overall menu spec implementation at http://mozilla.org/projects/ui/menus/shortcut/, but there could be lots worse problems than there are. As to preferences... I love having more preferences (providing they are well organized and accessible) - but I can also fully understand the need to limit them. I think an external application can be a good substitute, however, and way back when Aaron Anderson created one to edit the context menus. It seemed to work well but hasn't been updated since 0.9.6. http://www.xulplanet.com/downloads/view.cgi?category=applications&view=contexteditor Maybe when 1.0 comes out we'll get an update :-) My screen is typically at 1600x1200 res these days, so context menus never look as long to me as they do to those with lower res. Anyway, you say that you would like to see Back and Forward re-added, but I personally have almost no use for them at all. It is a good example of why such things should be customizable. If they are always at the top of the context menu then I would always have to move past them to get to what I want, so I'd prefer that they just were not there. However I can see why some people like you want them. I had not seen Aaron's context menu editor, but it sounds highly useful. I will have to check it out in more detail this weekend. XUL used to be simple like making Menu's and tool bars using AutoLISP in autocad.. now I need to learn C++ and Assembley and Java and Fortran customize it. XUL used to be simple like making Menu's and tool bars using AutoLISP in autocad.. now I need to learn C++ and Assembley and Java and Fortran customize it. XUL used to be simple like making Menu's and tool bars using AutoLISP in autocad.. now I need to learn C++ and Assembley and Java and Fortran customize it. XUL used to be simple like making Menu's and tool bars using AutoLISP in autocad.. now I need to learn C++ and Assembley and Java and Fortran customize it. XUL used to be simple like making Menu's and tool bars using AutoLISP in autocad.. now I need to learn C++ and Assembley and Java and Fortran customize it. XUL used to be simple like making Menu's and tool bars using AutoLISP in autocad.. now I need to learn C++ and Assembley and Java and Fortran customize it. XUL used to be simple like making Menu's and tool bars using AutoLISP in autocad.. now I need to learn C++ and Assembley and Java and Fortran customize it. >Now Mozilla's design team, understood... I believe, "Mozilla's Satanic Desing Team", fits better. I've always found, in most of the applications, ILLOGICAL the arrange of the menu items; and almost an idiocy the fact that: [File], [Edit], etc; always appear and are always in first place at left, in most of the applications. Mozilla seems trying to follow this order, but it does it with very bad results. The Mozilla's menu bar is almost a joke. I think that a context menu that is really long isnt a good idea, because you need more time to find the correct entry. But there are two possible solutions: make a second-level entry for less important actions (e.g. view source) and make it configurable (e.g. for back). A good reason why one could want the back button and other things in the context menu is for those damned sites that take away your toolbars with ajavascript when opening and page. And for those which do something that doesnt work (e.g. some plugin) and you want to do a view source to download the damned thing manually. Configurable context menus are important. But without it please don't change the context menu any more. I don't understand why there is such a need for having the same navigation buttons that are already there for single click access, in the context menu at first position. Same could be said for standard menu items that are easy to access. But Frame items like view frame source or reload frame that aren't easy to access anywhere else are moved to a submenu of the context menu. For those who don't want to move the mouse to the top of the window I suggest using Optimoz as it's even easier than having navigation buttons in the context menu. I personally, think that Back and Forward in the context menu is stupid, but the beauty of mozilla is that the interface is all in XUL/JS so you can easily change it to suit yourself with nothing more than a zip utility and a text editor. All it takes is for someone who thinks that this is a good idea to work out how and write a little script to do it. To start with I am a programmer, but I don't know much about how Mozilla works. And you probably need to get patchmaker http://www.gerv.net/software/patch-maker/build-mode.html since that is the easiest way to get the chrome files into a form where you can hack around with them. It looks like the context menu is defined in the file \comm\content\communicator\contentAreaContextOverlay.xul, but this file just defines all the possible entries, they are hidden or shown elsewhere. Anyway, the bit of code we are interested in is <menuitem id="context-back" label="&goBackCmd.label;" accesskey="&goBackCmd.accesskey;" oncommand="BrowserBack()"/> <menuitem id="context-forward" label="&goForwardCmd.label;" accesskey="&goForwardCmd.accesskey;" oncommand="BrowserForward()"/> <menuitem id="context-reload" label="&reloadCmd.label;" accesskey="&reloadCmd.accesskey;" oncommand="BrowserReload();"/> <menuitem id="context-stop" label="&stopCmd.label;" accesskey="&stopCmd.accesskey;" disabled="true" oncommand="BrowserStop();"/> That is, we are now looking for the code that messes with the things with id context-back. A quick search throught the other files suggests that the code we want is in nsContextMenu.js and looks like this: initNavigationItems : function () { // Back determined by canGoBack broadcaster. this.setItemAttrFromNode( "context-back", "disabled", "canGoBack" ); // Forward determined by canGoForward broadcaster. this.setItemAttrFromNode( "context-forward", "disabled", "canGoForward" ); this.showItem( "context-back", !( this.isTextSelected || this.onLink || this.onImage || this.onTextInput ) ); this.showItem( "context-forward", !( this.isTextSelected || this.onLink || this.onImage || this.onTextInput ) ); this.showItem( "context-reload", !( this.isTextSelected || this.onLink || this.onImage || this.onTextInput ) ); this.showItem( "context-stop", !( this.isTextSelected || this.onLink || this.onImage || this.onTextInput ) ); this.showItem( "context-sep-stop", !( this.isTextSelected || this.onLink || this.onImage || this.onTextInput ) ); // XXX: Stop is determined in navigator.js; the canStop broadcaster is broken //this.setItemAttrFromNode( "context-stop", "disabled", "canStop" ); }, I would guess that changing some of those compicated logical conditions to just read "true" or "false" would do what you want. I have not tried this yet since that would require exiting Mozilla, I'll report back soon. Tim. First, sorry about the fact that the code above all got munged onto one line in my previous post. Not my fault. Second, if you download patchmaker form the link above and follow the instructions then editing the chrome is easy. In this case you want to experiment with comm/content/communicator/nsContextMenu.js rather than content/navigator/navigator.xul which is what is suggested in the "Trying it out" part of the patchmaker instructions. And for the change you want, all that is required is to comment out the two lines that hide these context items, so thay they now look like: //this.showItem( "context-back", !( this.isTextSelected || this.onLink || this.onImage || this.onTextInput ) ); //this.showItem( "context-forward", !( this.isTextSelected || this.onLink || this.onImage || this.onTextInput ) ); You may also want to reorder the .xul file so that these items come nearer the top of the context menu. Anyway, I don't care about that. What annoys me is having "open link in new tab at the top" when I never use that and do what open in new window. But now it is fixed, I love Moz. Tim. Thanks for the valuable info, but it's not what I had in mind when I was talking about configurable - many users who dont like the context menu, however it is implemented, won't be able or willing to delve that deep into XUL and Javascript ... But something like the Context Editor <http://www.xulplanet.com/downloads/view.cgi?category=applications&view=contexteditor> does seem like a good idea? Something similar to this could easily be built into Mozilla proper and close to everybody could be made happy ... The only reason for having "Back" in the context menu is for when the browser window has no menus and the Navigation Toolbar is hidden. I realize that some people want it at other times too, but in the scenario stated, the context menu is the only way to go back. SubtleRebel said: "The only reason for having "Back" in the context menu is for when the browser window has no menus and the Navigation Toolbar is hidden. I realize that some people want it at other times too, but in the scenario stated, the context menu is the only way to go back." And what's wrong with Alt+Left Arrow on those rare occasions where you find yourself in that scenario? Do those pages also disable keyboard input or something? --Asa 1) precedence ( on Unix anyway ) 2) right-click takes one hand. This is useful on image galleries, since the can sometimes take up the whole screen ( thumbnails -> large images, etc ). You do the math. Alt+Left Arrow does not seem to do anything for me on Mac OS X build 2002041603. With minimal investigation though I discovered that Cmd+Left Arrow does go back though ;) -- provided of course that focus is not on a form field. Even though I am now aware of a keyboard based means to go Back, it really is not equivalent to a context menu option because it can not be done with the mouse and my hand is usually on the mouse. Anyway, as I have said, for my personal use, I generally would prefer not to have the Back and Foward items on the context menu, but I see no reason not to allow others to have them there if they want. In general I think the new context sensitive menus work just fine. One thing that I would change would be to change the context sensitive menus for frames. Currently, when right clicking on a framed area I get the Option of "This Frame" and there are frame related options there. Personally I think the menu should be swapped. That is to say, the main menu should be the frame stuff and the 'This Frame' should be 'This Page'. My guess, from my experience, is that most are heading to the frame stuff when on a framed page. Why do I need to view the Page source? So I can see the frameset info? Mostly useless compared to the frame source.. Maybe it's only when you're working on webpages (like I do) but this is really painful to have to search for two entries in the context menu for accessing an often needed function. I think it would even have been easier to have one large context menu... >... >...Option of "This Frame" and there are frame related >options there... i believe, "This Frame" submenu, is the first thing, made by "...Mozilla's design team...", where i can find a little of a coherent **language. ** With the word "language", i am talking about the communication between the user and the application, not XUL... I think if I click on a frame, it should only show the "this frame" menu (or may be include the "View Background Image" option if there's one. The "Page Source" on "View---->Page Source" is good enough. Not many people are trying to view the "page source" when clicking on a frame anyways. I like the idea of some context-sensitivity in the menus. For instance, if I right-click over a text link, there's no need for image-related stuff. I would really like to see "Open Link in New Tab" retained. I have my mouse wheel button configured to do a double-click. I would also like to have an "Open Frame in New Tab" item along with "Open Frame in New Window" for frames pages. I haven't been over here (at MozZine) recently. I am concerned about our obvious intention to release 1.0 without a spellcheck for the composition of outgoing mail. If we want to be a competitive (to say nothing of world class) I think that this will be taken by 'baby' end users as a SHOW-STOPPING defect: 1) They'll be confused by that grayed out icon 2) They'll be confused by the discussion in 'help' 3) To them, it's unthinkable to clip and paste between apps to do your spell checking done. 4) They expect the Released Product to replace IE/Exchange, and without a spellcheck, they'll go ballistic. 5) After they go ballistic, you can't tell them to wait for Mozilla 1.1. Even though the drivers are trying to move towards an RC1 this next week, I prefer that we not Release the Product until it's ready for use as expected by its intended market. If there is now a 'schedule' which MUST be met, then I think that someone or some team needs to start spreading the word and setting expectations about the lack of an EMail spell checker in this release. #93 Re: Sorry, mail/news WITHOUT spellcheck is DOA.by garfieldbond Saturday April 13th, 2002 1:58 PM Isn't there a spellcheck project at Mozdev? And in any case, the commercial releases have their own option to add spellcheck, and really, that's who Moz is targeting (the fact that Moz can make a good enduser product without the need for commercial releases is a cool fringe benefit =) #1 My thanks (garfieldbond and GAThrawn) for pointing to the project, which does appear to recognize the need for spell-check integration. #2 Thanks to GAThrawn for explaining how OE depends on MS-Office to provide spell-check functionality (I have only used "full" Outlook on Windoz PC's with Office installed, and was not aware of this dependency. #3 However, let me expand my complaint regarding 'baby' end users: in many places, mozilla.org site information portrays our RASUI requirements for 1.0 to be much higher (than either pre-release nightly builds and 0.9.x milestones), allowing for non-expert use without confusion or crashing or data loss. And, it is explicitly statethat Mozilla is intended to provide "Open Access to the Net" for hackers and mass market consumers". "Mass market consumers" sounds nearly synonymous for 'baby end users' to me. I feel that the "Developer-only" response which I provoked IS a reasonable strategy. BUT, if this is the strategy for the Mozilla Browser, then the mozilla.org site should be cleaned up to reflect this. And, the Community should take steps to publicize this fact in upcoming press articles. To date, I've seen nothing about 1.0 being intended 'for Developers and Hackers only' within press articles regarding the upcoming release. I am delighted to see that the spellchecker is tentatively targeted for 1.1, and still consider it to be an extremely significant feature for the mail/news components. Thanks again, Rick "I feel that the "Developer-only" response which I provoked IS a reasonable strategy. BUT, if this is the strategy for the Mozilla Browser, then the mozilla.org site should be cleaned up to reflect this. And, the Community should take steps to publicize this fact in upcoming press articles. To date, I've seen nothing about 1.0 being intended 'for Developers and Hackers only' within press articles regarding the upcoming release." Huh? From http://mozilla.org/releases/: "We make binary versions of of Mozilla available for testing purposes only!". From http://mozilla.org/: "We provide binaries for testing and feedback." The primary (or only, some will argue) purpose of Mozilla 1.0 is to freeze the APIs. It is not in any way intended to be an end-user release. > I am concerned about our obvious intention to release 1.0 without a > spellcheck for the composition of outgoing mail. Have you ever used Outlook Express? Do you think it is "ready for use as expected by its intended market"? Outlook Express does not have a Spellchecker, no one winges about that and calls is "DOA" for that reason. (and before anyone jumps down my throat saying that their copy of OE has a spellchecker, it's only because you've got an MS Office app installed too and OE is using the MS Office spelchecker engine, anyone who hasn't got Office installed hasn't got a spellchecker). In fact on PCs without any MS Office app installed OE actually has a "grayed out icon" for spell checking. No one's pointed this out as a "SHOW-STOPPING defect". If you want a spellchecker in Mozilla's mail/news go to http://spellchecker.mozdev.org/ and install it, I use that Moz spellchecker and it works fine, I've even got proper UK English spelling installed for it with no problem. >Even though the drivers are trying to move towards an RC1 this next week, I prefer that we not Release the Product until it's ready for use as expected by its intended market. If there is now a 'schedule' which MUST be met, then I think that someone or some team needs to start spreading the word and setting expectations about the lack of an EMail spell checker in this release. Just who is this intended market? Mozilla is not an enduser product, remember all those words you scrolled past last time you downloaded a milestone from Mozilla.org? They state that Mozilla binaries are released for testing purposes only. If you want a version of Mozilla that is aimed at end-users, then download Netscape 6. It even has a built in spellchecker so that your "'baby' end users" don't get confused. > this will be taken by 'baby' end users Who should not be using a product that is clearly marked as being for testing and development only. For one thing, such users want support, which mozilla.org does not provide... Not to mention their grammar? ;-) Apperantly Netscape is logging searches that are entered into the side bar. Nice one. http://www.newsbytes.com/news/02/175035.html Please notice: I will in any case write a similar patch for 1.0 Here's one I wrote for my current nightly build (ID 2002041408), should also work with slightly newer builds, unless they really applied some major changes to the menu handling. Download it here: http://tgos.org/mozilla/comm.zip Inside is a file named "comm.jar". This file is supposed to be replaced with the file located at MOZILLA_INSTALL_DIRECTORY\chrome\comm.jar Of curse you are strongly advised to back-up the original file, e.g. by renaming it to comm.jar.bak or similar. Here is what I changed: * Navigation context menu entries ([Back], [Forward], [Reload] & [Stop]) are back again and appear always on top of the menu, unlike you clicked onto a link (this includes pictures that are links) or onto a text form element (text line or text area), in these two cases it's not on the menu at all (but it's also on the menu if you have selected text on the page) * [Back] only appears on the menu if there actually is a page to go back to (IOW, it's only there if the back-navigation-button is not disabled). Same is true for [Forward] * [Stop] and [Reload] never appear both at the same time. If currently a page is loading, only [Stop] appears there, if no page is loading, only [Reload] appears there. * If you open the context menu while the page is still loading (so [Stop] is displayed) and you keep it open till the page finishes loading, [Stop] is not replaced with [Reload]. That's what I wanted to do, but it causes the menu to jumps somewhere else on your screen and then blocks till you right-click to open another context menu (maybe some internal bug?). Instead [Stop] should go disabled and if you want reload through context menu, simply right-click again to get a new context-menu. * The stop-navigation-button was by default enabled when you opened the browser (even though no page loading was taking place), I fixed that (now it's only enabled when you load a page for the first time). * The reload-navigation-button is now only active if no loading is taking place (used to be active all the time in my nightly build), I fixed that (now it's only active after the page has finished loading or the loading process was stopped) * Removed [Save Page As] of the context menu, as you don't need that a lot and you can always go to the file menu or the keyboard shortcut. * Removed [Bookmark This Page] of the context menu, as you can also use the Bookmark menu for that or the keyboard shortcut (despite that, someone complained that bookmarking through context menu always destroys the order of bookmarks and forces the user to open the Bookmark manager and put the Bookmark where it really belongs or similar). [Bookmark Link] is still there when clicking on a link and [Bookmark This Frame] is also still there on frame pages (because you can't easily do that without the context menu IMHO). * Removed [Set Wallpaper] (or similar) of the context menu, as how often a day to you make an image your wallpaper ? You can still store the image to disk and then select it as wallpaper the regular way. This is of course just a first try, I'm open to suggestions. If it leads to strange results or does not work as desired, simply delete the file again and restore your back-up of the original comm.jar file. You can only replace the files while Mozilla is not running, I think. |