From Bugzilla Helper: User-Agent: Mozilla/5.0 (Macintosh; N; PPC; en-US; m17) Gecko/20000626 BuildID: 2000062608 The chatzilla mode does not have a file menu. Mac users expect to see a file menu in all parts of an application because that is where they go to quit. Reproducible: Always Steps to Reproduce: 1.Open chatzilla 2.Notice that there is no file menu Actual Results: There is no file menu Expected Results: Displayed a file menu

A quit command is required to comply with the Apple Human Interface Guidelines. They state: The Quit command lets the user leave the application and return to the Finder, or another open application. If any open documents have been changed since the last time they were saved, present the standard save changes alert box, once for each open document. This alert box is described in the section "Close" on page 79. The HIG also state that the same menus should stay in the menubar at all times. Now that I look through the componants again, maybe I should move this bug to XP menus.

A quit command is required to comply with the Apple Human Interface Guidelines. They state: The Quit command lets the user leave the application and return to the Finder, or another open application. If any open documents have been changed since the last time they were saved, present the standard save changes alert box, once for each open document. This alert box is described in the section "Close" on page 79. The HIG also state that the same menus should stay in the menubar at all times. Now that I look through the componants again, maybe I should move this bug to XP menus.

Changing componant and reassigning to owner of the XP menu componant.

Um, no. This was in the right place to begin with. The menus (xp and native) are fully capable of supporting a Quit menuitem. If it is not present in a particular application, then that is an issue for the application code. (Of course, rginda can choose any UI style he wants, since he is the owner of this code).

Sorry about that. It seemed right to me.

mass accepting chatzilla bugs and marking "future"

*MASS SPAM* Changing QA contact on all open or unverified ChatZilla bugs to me, David Krause, as I am now the QA contact for this component.

attaching a patch. File->Close handles the closing of chatzilla by calling window.close() ,which in turn calls onUnload() function. File->Quit also relies on using window.close() through a call in goQuitApplication() function in globalOverlay.js I note that the closing of chatzilla is slightly different where the user types the command /exit <partmsg> . Perhaps with the partmsg a preference should be used so that that the msg can be used from the menu/key handler. Also as a sidenote I see that with regard to /exit command, the following sequence takes place. client.quit(msg); window.close(); ..calls onUnload(); ...calls client.quit("Chatzilla"...); So client.quit is being called twice, Im not sure if this is intentional. However even if it is not, the end result is minimal(the client checks it is not connected to any networks again with 'for (var n in client.networks)...' and I presume client.networks would be null if successfully disconnected already.

superbug checked in, mass marking all dependents fixed.

vrfy per bonsai