96940 - Menu->Help->About Plug-ins won't open new window

Status: VERIFIED DUPLICATE of bug 250624

(SeaMonkey :: UI Design, defect, P5)

Description

[Darrel Liu]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.3) Gecko/20010801
BuildID:    2001080110

Menu->Help->About Plug-ins won't open new window, which I think it should, as
Help->About Mozilla does.

Reproducible: Always
Steps to Reproduce:
1. Menu->Help->About Plug-ins

Actual Results:  The current window is replaced by Plug-in information.

Expected Results:  A new window opens up, current window is reserved.

Comment 1

[David Illsley]

Confirming because I can't find a DUPE and it seems to makes sense

Comment 2

[sairuh (rarely reading bugmail)]

p5 and future

Comment 3

[Neil Marshall]

Attachment: Opens aboutplugins in a new window instead of the top window.

Comment 4

[Matthew T (active 1999-2002)]

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

Comment 5

[Brian Ryner (not reading)]

Comment on attachment 53902 [details] [diff] [review]
Opens aboutplugins in a new window instead of the top window.

r=bryner

Comment 6

[John Morrison]

Please, no. Make 'Help->About Mozilla' open in the current window. It's not
a modal dialog, so why open a window at all.

Comment 7

[Jeremy M. Dolan]

Yes, it's really annoying I have to wait 5 seconds for a new window to spawn
just to check my plugins or look at the about screen.

4.x (and probably 1.x, 2.x, and 3.x) used the same window for help->about, so
the whole thing about users expecting help->about to be in a new window may
actually be reverse.

Comment 8

[David Hyatt]

I disagree with this bug and believe it should be closed as WONTFIX.  I cannot
sr this.

Comment 9

[[not reading bugmail]]

I dont like this: about objects should either open a new window or open a new
tab too.. not load into my browser windows I wanna keep open and am looking at..
What if I'm on a web page that requires x plugin.. I wanna load to see if I have
x plugin in Mozilla installed.. why should it open in window I really wanna keep
open.  I gotta hit the back button after I view about:plugins, Unless I manually
open a tab for this.. novice users wont know this if tabs make it to NS x
products ->then will become annoying which it is already for us using Mozilla
everyday.

Comment 10

[Jeremy M. Dolan]

> I gotta hit the back button after I view about:plugins

Our back performance is alot better then window open.

> I dont like this

Hit control-N first. This isn't rocket science. It's easy to open in a new
window if you want to. If the code forces it, it's not easy to open in the same.

These really should be made consistent before 1.0... I (obviously) vote to make
about mozilla also load in the current Nav.

Comment 11

[Jeremy M. Dolan]

Is this in the right component?

help->release notes opens in the current window
help->about plugins opens in the current window
help->about mozilla opens a new window (which takes 6.5 seconds on my machine)
to show a tiny bit of information.

This isn't rocket science. Let's make them all consistent and fast by opening
all three in the current window for now. If new window performance is ever
acceptable, we can debate which way they should all work then.

Comment 12

[sairuh (rarely reading bugmail)]

->trudelle for triage.

Comment 13

[Peter Trudelle]

I think novice users are less likely to be able to cope with a new window than
with a page loading in the current window. Performance characteristics would
seem to preclude bringing up a new window too.  resolving as wontfix

Comment 14

[sairuh (rarely reading bugmail)]

v

Comment 15

[Jeremy M. Dolan]

I've reopened bug 101167 due to the resolution (which I agree with) here.

Comment 16

[R.K.Aa.]

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

Comment 17

[János Holányi]

CAVEAT: if you make Help->About items open in the same window, you will delete
the data entered and not submit yet in forms in the window you'll open About's into.

This is true especially if the user has
'Compare the page in the cache to the page on the network Every time I view the
page' set under Preferences/Advanced/Cache.

So in that case (me, for example) there will be no way to get back the
previously entered data (and thus *loosing* already entered data).

I believe that every menu option should open new windows for what they want to
display and not mess with the user's active window in any and all of the cases
(as for example, in the case of the Preferences or Search options)

Also, imagine how annoying would it be if the user has an IMP (webmail) session
open and Moz would open the About page in the same window... :)

Thanks.

Comment 18

[John Morrison]

Your comment isn't a novel argument. This was already decided. It's over.

Comment 19

[John Morrison]

v

Comment 20

[János Holányi]

Sure, it is up to you to decide.
But maybe you didn't think about this small detail I'm trying to draw attention
to here... (BTW, I haven't read any similar comments).

It would be a little peculiar to accept that performance is more important than
data persistency for the Mozilla project  ;) I can't.

Again, I'm trying to draw attention to the fact that in quite common cases users
might <u><b>*lose*</b></u> data. :)

An example: I was filling up the Bugzilla Helper to report about a bug. After I
spent like 1 hour to fill up all the ory details, to write a step-by-step
procedure, verifying it and write a lot of details into the form, I just needed
1 more detail (the exact Build ID). I wanted to check this in the About: Mozilla
page, so I tried to open it. But, accidentally, I clicked on Plug-ins.

Whoooosh! All my data already entered in the current page was overwritten by the
plug-ins page.

Ok, you could say "no problem, hit Back and you're back to the filled form".
Unfortunately, no. I have 'Compare the page in the cache to the page on the
network Every time I view the page' option set under Preferences/Advanced/Cache.
Therefore hitting the Back button will download the empty page from Bugzilla.

This behavior is barey acceptable.

But I can describe another example: Using any webmail account, you are composing
an long email and right before you finish, you want to include/check some
Plug-in details of your Mozilla browser. You hit the menu and whoooosh again,
all your long letter is just gone (yes, only if 'Compare the page in the cache
to the page on the network Every time I view the page' is set under
Preferences/Advanced/Cache.

Would it be too difficult to not open a whole new browser window for these
static data (About: Mozilla and About: plugins), but instead to open a smaller 
informative menu window (like Preferences, or "Find in this page" items do)?

As a summary: I'd really like to use a browser for my work and entertainment
which would *not* cause losing my data in any circumstances... ;)
Thanks a lot for your cooperation, anyway... :/

Comment 21

[Peter Trudelle]

reopening for consideration in a future release.

Comment 22

[Karl Palsson]

Another example of data loss and friends is when you were on the results page
from a POST.  (Eg a credit card transaction) and pressing back says, "do you
want to resubmit your form details? retry/cancel" Which you sort of don't want
to do if you're buying tickets or something, and therefore you have to press
cancel, which means your confirmation code or whatever is all gone byebyes. 
Dataloss bugs elsewhere seem to be mega high priority.  Perf is too of course :)
 But is the perf of a help-about... dialog as important as the perf of the
rendering or any other part that is used day in day out, full time? I would vote
not.

It is my opinion that the only things that should ever change the frame I'm in
are Reload, Forward, Back and choosing a bookmark.

But maybe that's just me :)

Cheers,
Karl P

Comment 23

[Jeremy M. Dolan]

Karl, that sounds like a cache issue. The page shouldn't expire by loading
about:plugins. That is not relevant to having Help menu entries shown in a sane way.

Comment 24

[Peter Trudelle]

Mass moving all of my open Nav/toolkit bugs to new owner.

Comment 25

[R.K.Aa.]

there's a patch in bug 250624

Comment 26

[OstGote!]

Resolving to a bug with a current patch.

*** This bug has been marked as a duplicate of 250624 ***