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)
SeaMonkey
UI Design
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.
Comment 1•24 years ago
|
||
updating component.
Assignee: asa → don
Component: Browser-General → XP Apps
QA Contact: doronr → sairuh
Comment 2•24 years ago
|
||
mpt, what do you think?
Comment 3•24 years ago
|
||
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:-).
Comment 4•24 years ago
|
||
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
Comment 7•23 years ago
|
||
-> default assignee
Assignee: pchen → trudelle
Target Milestone: Future → ---
Updated•23 years ago
|
Target Milestone: --- → Future
Comment 8•22 years ago
|
||
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 9•22 years ago
|
||
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).
Comment 10•22 years ago
|
||
Mass moving all of my open Nav/toolkit bugs to new owner.
Assignee: trudelle → sgehani
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
Comment 11•15 years ago
|
||
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
Comment 12•15 years ago
|
||
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
Comment 13•15 years ago
|
||
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
Comment 14•15 years ago
|
||
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
Comment 15•15 years ago
|
||
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
Comment 16•14 years ago
|
||
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.
Description
•