* TITLE/SUMMARY Seamonkey About box should open in new window * GENERAL FOO The current behavior of replacing the user's existing web browsing content with the about box is inconsistent with the behavior of all other applications' About boxes, and has resulted in a multitude of user complaints from confused users. (I'd be happy to paste a few of these examples in, but then I'd have to remove this bug from public view. Or, I could just provide a few use case scenario examples.) German agrees with this opinion.

This is an enhancement. I'll talk to John about it ...

Updating QA Contact.

...actually, that should be me. Corrected.

This is fine for "About Mozilla" menu item, but I wouldn't want to do it for "about:", which I imagine will show much the same thing inline. I'm not sure if you were implying that.

Thanks for making the distinction; yup, I specifically meant the scenario in which the user selects an About menu item.

Marking depends on bug 6000, the about menu item bug.

*** Bug 14270 has been marked as a duplicate of this bug. ***

Attached are some XUL & Javascript files which implement a simple about dialog box in Mozilla. Hope someone can look it over and check it into the tree.

marking a dup of 6000. I would say the about menu item should do the equivalent of a window.open("about:") *** This bug has been marked as a duplicate of 6000 ***

Reassign to German to decide whether the about box should open a seperate browser window, or a dialog box (like IE and my attachment to this bug).

I disagree. About menu items are expected to be in new windows, and URLs entered are expected to be inline.

Matty, could you explain you last comment further. It is not clear who you are disagreeing with.

I disagree with davidm, noone else has made any assertion recently.

I think David was also suggesting that the menu item should open a new window. The difference in opinion between David and myself concerns whether the About menu item should open a dialog box or a whole new browser window (with or without the toolbars/sidebar) to display the about: page. I think the former is preferable because it is more flexible, and it is what the user expects. Are you agreeing with the dialog box solution too Matt (it looks like you are, but it's not 100% explicitly clear)?

Sorry, I don't know how I read what I did into that. I think a dialog would be better but a new browser window would probably be simpler to implement straight away.

Simplicity is not a problem for the dialog box solution, since I've already done the work. Even if it has to be changed it would take a trivial ammount of time to get this checked in. An About dialog box would make Mozilla look much more professional and spiffy than the current 4.x about menu solution, or opening a new browser window.

It should be a modal dialog (no chrome). Looking up the about box is a temporary action and should not interrupt or blow away your current task context. Re-assigning back to Don as RFE.

Note that my attached solution is just a modal dialog wrapper for the about: URL (as per German's spec). The html code that does this is: <html:iframe style="border: 1px outset #CCCCDD;" src="about:"/>

Matt: any chance of getting this checked into the tree soon? Thanks.

When selecting Help->about in composer, the about page is opened in an composer window. This is with the nightly build for 26-oct-99

Re-evaluate this after beta 1 ...

Taking this bug to redo dialog.

Michael, i was all set to check these patches in when the tree opens. I'm more freed up now after we got some extra help. Sorry i didn't get this in earlier i just had other things on my plate. Give me a yell if you need help.

Matt: if you're already set to checkin then be my guest - saves having for me to do it again. Otherwise, let me know and I'll take over this bug. Thanks.

Matt: if you're already set to checkin then be my guest - saves having for me to do it again. Otherwise, let me know and I'll take over this bug. Thanks.

Checked in

Re-opening, as making this dialog modal really seems like the wrong fix to me. Suppose someone wants to cut-n-paste or print the dialog, or even refer back to it while typing in a chatzilla window?

dmose@mozilla.org: what you want is still available if you type in about:mozilla into the url bar. I don't see 99.9% of users needing this sort of control in the about box. Maybe we could add a popup menu to the dialog box to allow printing. Also, I think there should be a global perference for _all_ dialog boxes in Mozilla to indicate if they should be modal or non-modal. The default setting should be modal, but 'power-users' like yourself obviously don't like modal dialogs.

Clearing FIXED resolution due to reopen.

Why would anyone, even a first-timer, want a help dialog to be modal, so that you can't check out URLs, copy from the dialog into an editor, or anything else useful while the dialog is up?

> Why would anyone, even a first-timer, want a help dialog to be modal, so that you can't check out URLs, copy from the dialog into an editor, or anything else useful while the dialog is up? I don't see how being window modal prevents any of this. You can copy text from a modal dialog, click on urls and how them open into a new browser, and if you hook up a popup menu, print the text.

if the dialog is up, and you copy something, you can't paste in to composer while it is still up. There is *no* reason for this dialog to be modal. The only reason modal dialogs should ever be used is in a case where you have to stop and have user input before you can continue. The about box is surely not one of these.

> There is *no* reason for this dialog to be modal. The only reason modal dialogs should ever be used is in a case where you have to stop and have user input before you can continue. I disagree. I believe studies have shown inexperienced users often open a non-modal window, click on something else, and then later try to open the same dialog again, leading to _multiple_ open instances of the same dialog. In this case the fix is simple - make the about box non-modal, but only allow at most one instance of the dialog. If the dialog is already open but not in front, and the user chooses the "About Mozilla" menu item, the existing about dialog is brought to the front.

Agreeing with Pavlov. There is no reason this dialog should be modal. Making it "one instance only" and "pop to the front if it's already up" is a much better solution.

sure. that works fine.

Reassigning bug to myself.

Could somebody review the attached patch file so I can check it into the tree please - (pavlov, etc?). This patch file changes the about menu item so it opens a non-modal dialog. Any attempts to open the About dialog while another is already open should bring the existing About dialog to the front of the screen.

Can we get an update on this bug, please? fixed?

The About box works, if you enable `Show About box as modal dialog (woohoo)' in Debug preferences. However, it has a couple of bugs which I'm adding as dependencies here. So I'd say this bug can be resolved fixed when: * the dependencies are fixed (since they're both reasonably serious, and neither of them occur with the traditional in-the-browser About display) * Mozilla is set to always open the About info in a dialog, and the pref for it is removed.

Actually, this bug was originally filed to have the about page open in a new _Mozilla_ window, instead of inline (like about:) as it had been doing when it was reported. And general concession (as gathered from some of the comments here) seems to be that, by default, the about box shouldn't be modal. Thus, this is really FIXED now... However, on 2/13, Michael attached a patch that will seemingly open the About page in a non-modal popup window (which I'd prefer over the current system, which opens in it a full new browser window) and asked that someone review it. Any devs out there with a little time on their hands?

M16 has been out for a while now, these bugs target milestones need to be updated.

credits in the about dialog are horribly out of date. You're using a copy of the real credits page which hasn't been updated since it was checked in last january. You should use the real credits page at http://mozilla.org/credits/index.html directly or change the build automation so it grabs the page from the web site's cvs tree instead of trying to keep it in the source tree. The idea of keeping a second copy of the file in the source tree is doomed because no one will think to update it except for people like pepper who add themselves to the wrong list. http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/xpfe/global/resources/content/credits.html

It looks like the original bug here is fixed. Would anyone like to split off the bugs that have been added to this bug, and mark it as RESOLVED for verification?

Aha... I found this problem, but it seems that Dawn got there a week before me. I think we need to let people access the About dialog offline, so we need to ship a credits.html. So, this means changing the build automation. CCing leaf :-) Gerv

Leaf: Does the build now pull the credits page from the website to ship it, or do we have to remember to check in a new version just before each release? If so, whose responsibility is it? :-) Gerv

This seems to be a dup of bug 40024. cc'ing benb.

credits.html in the source tree is a manual, modified copy of the website's one. See bug 40024.

Milestone 0.8 has been released. We should either resolve this bug or update its milestone.

About now opens in new window. Resolving FIXED. We should be looking at bug 40024, though... Gerv

About now opens in new window. Resolving FIXED. We should be looking at bug 40024, though... Gerv

Ah. This would be Bugzilla breaking again when resolving bugs as part of a mid-air collision. Gerv

ReFIXing. Gerv

Help > About Mozilla now opens in a new browser window [2001.05.25.08 moz bits on linux].