Closed Bug 15555 Opened 25 years ago Closed 24 years ago

popup browser window attributes should not persist to real browsers

Categories

(Core :: XUL, defect, P3)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: yossioren, Assigned: bryner)

References

()

Details

(Keywords: regression, Whiteboard: [nsbeta2+])

Attachments

(1 file)

1. Go to a page that opens a popup (i.e. www.netscape.com, or the attachment)
2. Close the popup, click view-source.
3. The view-source window remembers the last position of the popup (which is
sorta OK), but it also remembers its fixed-sizedness and toolbar-lessness,
making it all but useless (this is a very small window we're talking here).
Attached file testcase
OS: other → Windows NT
Hardware: Other → PC
Summary: View|Source after a fixed-size popup inherits fixed-sizeness
(header fixed)
Assignee: shuang → trudelle
Component: UE/UI → XP Toolkit/Widgets
reassigning to toolkit team. Heads up guys, I think this is more than just view source
I believe that *any* new window inherits the size of the popup. It may also happen on
other platforms. I'll research and comment here shortly
Assignee: trudelle → danm
reassigning to danm
Status: NEW → ASSIGNED
Summary: View|Source after a fixed-size popup inherits fixed-sizeness → "pretend" browser window attributes should not persist to real browsers
Target Milestone: M13
Browser windows save their size (and their location, once bug 15775 is addressed), passing them
on to all subsequently opened browser windows. This is by design, but the current implementation
is too general. Popup windows, by which I mean informational and spam windows, and the like,
should not affect the size or location of real browser windows.
  We must distinguish between the two uses of browser chrome and make the size of only true
browser windows persistent. This may be as simple as not saving the size of any window opened
with an explicit size, or sized to content. Still thinking about that one.
*** Bug 18024 has been marked as a duplicate of this bug. ***
*** Bug 22530 has been marked as a duplicate of this bug. ***
*** Bug 21505 has been marked as a duplicate of this bug. ***
Blocks: 23280
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
The problem with solving this bug is differentiating between browser windows
that legitimately do want their size to be persistent (genuine browser windows)
and those that don't (popups). They're all really the same thing, so any distinction
made is somewhat arbitrary.
  Browser and popup windows have been tweaked to not persist their size if they
were opened as content (not chrome) and either a width or height was specified in
the JavaScript open call. This little bit of trickery should actually solve the problem
in every real-world example, though it'll be possible to fool it.
  NB: the original report mentioned that not only size persisted, but also chrome
features. I haven't seen that. Is that still a problem? If so, please include an example.
is this bug/ the fix XP? I ask because I'm trying to sync up all the comments with what I'm seeing
on Linux.
Yeah, there's nothing platform-specific about it. I wrote the fix
on a Windows box, though. Awaiting with trepidation your Linux observations.
no fear, I believe i was reading your comments incorrectly. I have not been able
however to use the testcase provided in this report and it has prevented me from
fully verifying this bug
Status: RESOLVED → VERIFIED
looks like popups weren't working yesterday but somehow are now. anyway,
this bug is VERIFIED fixed with 2000011908 builds on all platforms.
*** Bug 13208 has been marked as a duplicate of this bug. ***
Blocks: 24854
This is broken again on Linux build 2000.02.11.11.
Status: VERIFIED → REOPENED
Keywords: regression
Resolution: FIXED → ---
I remember Travis saying he wanted this to work differently. Did you change the 
way this works, Travis?
Assignee: danm → travis
Status: REOPENED → NEW
Target Milestone: M13
*** Bug 28199 has been marked as a duplicate of this bug. ***
Can't we do something like "don't remember size if target is set to something
other than the default", or "only remember size when user explicitly does a
resize"?  What does 4.x do?
OS: Windows NT → All
Hardware: PC → All
Yes, the fix for this is pretty known.  This was working but got regressed when 
we landed the new global Window code.  I'm working on APIs to do this in a 
general case so embedding works, it's just a lower priority to some of the 
other things as this is more of a slight annoyance rather than something that 
keeps you from using the product.
Status: NEW → ASSIGNED
*** Bug 29460 has been marked as a duplicate of this bug. ***
*** Bug 29731 has been marked as a duplicate of this bug. ***
*** Bug 31152 has been marked as a duplicate of this bug. ***
Is this the king of duplicates?
Would someone with permissions (travis, yossioren?) add a URL and some
keywords to Summary?
A geocities URL (e.g. in 31152) may be something people search for, and
add something like (popup pop-up banner) to the summary, that is what I 
searched for, and it's in most duplicates.

Axel
Summary: "pretend" browser window attributes should not persist to real browsers → popup browser window attributes should not persist to real browsers
Wow, seems I actually navigated Bugzilla successfully and found the bug I was 
looking for!  After reading the comments, I'm glad I didn't submit it as a new 
bug.  ;)
I think you guys are on the right track.  Windows that are opened at a specific 
size, other than what is currently the "default", are done so through JS.  If a 
user sizes a window (after creation, naturally), that resets the default.  If a 
window is created at X-by-Y, that does not reset the default.
Good job everyone.  Keep it up!!!
tim@r5i.com using M14 for Windows
Another case that triggers this is "View Source".  View source is very different
from general browsing, and resizes on the view source window shouldn't persist
onto all other browser windows, but they do.
*** Bug 33265 has been marked as a duplicate of this bug. ***
*** Bug 34038 has been marked as a duplicate of this bug. ***
travis, can we get a target milestone for this?
*** Bug 36057 has been marked as a duplicate of this bug. ***
Nominating for beta2, since this is a much-duped bug and makes us look stupid.
Keywords: nsbeta2
*** Bug 38448 has been marked as a duplicate of this bug. ***
Assignee: travis → trudelle
Status: ASSIGNED → NEW
Whiteboard: [nsbeta2+]
Putting on [nsbeta2+] radar for beta2 fix. 

trudelle, we are not sure who should own this.  Could you assign to appropriate 
engineer please?
assigning to danm as p3 for m16
Assignee: trudelle → danm
Target Milestone: --- → M16
Blocks: 40158
Mass-moving undated nsbeta2+ bugs to M18
Target Milestone: M16 → M18
Keywords: mostfreq
*** Bug 41676 has been marked as a duplicate of this bug. ***
*** Bug 42156 has been marked as a duplicate of this bug. ***
Assigning to myself, I'm well into fixing this.
Assignee: danm → bryner
Status: NEW → ASSIGNED
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago24 years ago
Resolution: --- → FIXED
VERIFIED Fixed on all platforms with a medley of current builds.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: