Closed Bug 56514 Opened 24 years ago Closed 14 years ago

Context-menu "Open in new window" opens link in new window the same size as the parent window

Categories

(SeaMonkey :: UI Design, defect, P3)

defect

Tracking

(Not tracked)

RESOLVED EXPIRED
Future

People

(Reporter: gerrychu, Assigned: samir_bugzilla)

Details

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
BuildID:    2000091312

When right-clicking a link and choosing "Open in new window" the new window 
opened should be the size of a sane default, such as a width a bit bigger than 
480 pixels to account for the scrollbar and sidebar size.

Why shouldn't the new window be the same size of the parent?  Let's look at why 
people open links in new windows in the first place: to open a link and keep 
the parent page _accessible_ at the same url.  Why do they want to keep the 
parent page accessible?  Because they want to finish reading the parent page 
and perhaps open more links links from the page.  Most regular users browse 
with mozilla's window pretty large.  When the new window is the same size as 
the large parent window they have two large windows open.  They want to get 
back to the parent window as fast as possible to continue reading it or to 
follow more links from there (as that's why people open links in new windows in 
the first place).  So currently, the child window is raised, and the user wants 
to get back to the parent window by clicking on it.  However, the area exposed 
for the user to click to raise the parent window is decreased dramatically
(sometimes to zero) by the child window which obscures most of the parent 
window!  Solution?  Make links in new windows open smaller so the area 
available to click to raise the parent window is larger.

Example?  I (and a lot of other people) read slashdot in a pretty large 
window.  We open links in the various news articles in new windows to finish 
reading the slashdot page itself.  When we do open those links, we try to raise 
slashdot back to the foreground quickly to try to finish reading it.  When the 
link in the new window is as large as the slashdot page, we have to move our 
mouse a long distance to get to an exposed part of the slashdot page or raise 
it by using the tasklist.  Slashdot would be raised quicker if the link in the 
new window was smaller so there would be a maximized area exposed of the 
slashdot window to raise it by clicking the window itself.  This problem is 
exerbated if the user opens a lot for links in new windows, in which he has to 
raise the original slashdot window that many times using the same laborious 
process over and over again.

Notice that I didn't say anything about the new window from the "file" menu, as 
that new window rightfully should be the same size as the parent window, 
because the user is most likily opening a new parent window that they will open 
links in new windows from.
updating component.
Assignee: asa → don
Component: Browser-General → XP Apps
QA Contact: doronr → sairuh
mpt, what do you think?
Yes -- this is exactly how I read Slashdot too, and I have to manually shrink my 
secondary windows to get the effect gerrychu describes.

This should be handled anyway by the offset for new windows, which should provide 
a large target area to get back to the primary window while still keeping the 
secondary windows the same size as the primary window. If the offset windows 
start approaching the bottom-right corner of the screen, though, then they would 
get smaller so as to stay completely on-screen.

If a window is maximized, then I think new windows opened from a link in that 
window should not be, as I described in bug 20847 on 2000-05-04.

See also bug 56690, which would open a link in a new window immediately behind 
the current window (ideally suited for Slashdot:-).
URL: Any
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hardware: PC → All
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
thanks,
	Vishy
Assignee: don → vishy
nav triage team:

We'll try to fix window offset for beta1, probably won't get to this one. 
Marking nsbeta1-, reassigning to pchen
Assignee: vishy → pchen
Keywords: nsbeta1-
Marking nsbeta1- bugs as future to get off the radar
Target Milestone: --- → Future
-> default assignee
Assignee: pchen → trudelle
Target Milestone: Future → ---
Target Milestone: --- → Future
I disagree with this request.  I set the window size I want, don't give me
windows of a different size.

The suggested behavior is worse in situations where I need to change my window
size for a web site -- the behavior would lose that information and open a
window where the web page wouldn't fit.
Comment #3 From Matthew `mpt' Thomas (gone)
> If a window is maximized, then I think new windows opened from a link in that
> window should not be, as I described in bug 20847 on 2000-05-04.

This bug is talking about the context-menu option "open in new window." Your
comments in bug 20847 suggest that the new menu should be the same size.

I nearly always use full-size (maximized) windows and would not want new windows
to open in a smaller window; this is one of my biggest complaints (second to
security) of Internet Explorer.

Personally I'd like to have all links open in the same window unless I told the
browser to open in a new window, then I'd want it in a new window (even
JavaScript links).
Mass moving all of my open Nav/toolkit bugs to new owner.
Assignee: trudelle → sgehani
Product: Core → Mozilla Application Suite
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.