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)
Core
XUL
Tracking
()
VERIFIED
FIXED
M18
People
(Reporter: yossioren, Assigned: bryner)
References
()
Details
(Keywords: regression, Whiteboard: [nsbeta2+])
Attachments
(1 file)
(deleted),
text/html
|
Details |
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).
Reporter | ||
Comment 1•25 years ago
|
||
Reporter | ||
Updated•25 years ago
|
OS: other → Windows NT
Hardware: Other → PC
Summary: View|Source after a fixed-size popup inherits fixed-sizeness
Reporter | ||
Comment 2•25 years ago
|
||
(header fixed)
Updated•25 years ago
|
Assignee: shuang → trudelle
Component: UE/UI → XP Toolkit/Widgets
Comment 3•25 years ago
|
||
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
Updated•25 years ago
|
Assignee: trudelle → danm
Comment 4•25 years ago
|
||
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.
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.
Comment 10•25 years ago
|
||
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.
Comment 11•25 years ago
|
||
Yeah, there's nothing platform-specific about it. I wrote the fix
on a Windows box, though. Awaiting with trepidation your Linux observations.
Comment 12•25 years ago
|
||
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
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 13•25 years ago
|
||
looks like popups weren't working yesterday but somehow are now. anyway,
this bug is VERIFIED fixed with 2000011908 builds on all platforms.
Comment 14•25 years ago
|
||
*** Bug 13208 has been marked as a duplicate of this bug. ***
Comment 15•25 years ago
|
||
This is broken again on Linux build 2000.02.11.11.
Comment 16•25 years ago
|
||
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
Comment 17•25 years ago
|
||
*** Bug 28199 has been marked as a duplicate of this bug. ***
Comment 18•25 years ago
|
||
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
Comment 19•25 years ago
|
||
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
Comment 20•25 years ago
|
||
*** Bug 29460 has been marked as a duplicate of this bug. ***
Comment 21•25 years ago
|
||
*** Bug 29731 has been marked as a duplicate of this bug. ***
Comment 22•25 years ago
|
||
*** Bug 31152 has been marked as a duplicate of this bug. ***
Comment 23•25 years ago
|
||
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
Updated•25 years ago
|
Summary: "pretend" browser window attributes should not persist to real browsers → popup browser window attributes should not persist to real browsers
Comment 24•25 years ago
|
||
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
Comment 25•25 years ago
|
||
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.
Comment 26•25 years ago
|
||
*** Bug 33265 has been marked as a duplicate of this bug. ***
Comment 27•25 years ago
|
||
*** Bug 34038 has been marked as a duplicate of this bug. ***
Comment 28•25 years ago
|
||
travis, can we get a target milestone for this?
Comment 29•25 years ago
|
||
*** Bug 36057 has been marked as a duplicate of this bug. ***
Comment 30•24 years ago
|
||
Nominating for beta2, since this is a much-duped bug and makes us look stupid.
Keywords: nsbeta2
Comment 31•24 years ago
|
||
*** Bug 38448 has been marked as a duplicate of this bug. ***
Assignee: travis → trudelle
Status: ASSIGNED → NEW
Whiteboard: [nsbeta2+]
Comment 32•24 years ago
|
||
Putting on [nsbeta2+] radar for beta2 fix.
trudelle, we are not sure who should own this. Could you assign to appropriate
engineer please?
Comment 33•24 years ago
|
||
assigning to danm as p3 for m16
Assignee: trudelle → danm
Target Milestone: --- → M16
Comment 35•24 years ago
|
||
*** Bug 41676 has been marked as a duplicate of this bug. ***
Comment 36•24 years ago
|
||
*** Bug 42156 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 37•24 years ago
|
||
Assigning to myself, I'm well into fixing this.
Assignee: danm → bryner
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 38•24 years ago
|
||
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED
Comment 39•24 years ago
|
||
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.
Description
•