Closed Bug 98701 Opened 20 years ago Closed 20 years ago

popup windows open maximized

Categories

(SeaMonkey :: UI Design, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.5

People

(Reporter: Matti, Assigned: danm.moz)

References

()

Details

Attachments

(1 file)

win2k build 20010907.. (CVS)

This is a regression from the last 24h.
Popup windows open now in a max state and also the software installation window.
Install the Aqua Theme :
http://www.simweb.net/eric/projects/Aqua/bulletin/cgi-bin/ib.cgi?action=list&id=0&directory=2

Danm : Is this a regression from bug 86955 ?
QA Contact: sairuh → claudius
This is indeed happenning, I See it to. And it's not QUITE maximized, but sized
so that it takes up the whole window. Maximized windows you can't move, but
these popups you can. The designated size is ignored and treated as if it was
set at the current screen resolution.

Example:
http://www.dynamic-core.net/widgetx/ has links that open a new window via JS,
such as:
javascript:openwindow('examples/vectorsine.htm',500,500)
but the window opens as if it was sized at current screen res.
This bug affects user browsing experience a lot...
Does it happen on 0.9.4-branch?
This was caused by my fix for bug 96745, which isn't (yet) on the 0.9.4 branch.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.5
Ah. Things are really out of whack here. It's embarrassing. But noticing
problems like this is the price you people pay for browsing with a maximized
window. :) Anyway, as far as I can tell, the patch below makes everything right
again.
Comment on attachment 48947 [details] [diff] [review]
reset zoom state when the window is sized or moved

r=jag
Attachment #48947 - Flags: review+
*** Bug 99265 has been marked as a duplicate of this bug. ***
please add "maximized" to the summary, to make this bug easier to find in a
query. as maximized is "the right" term for this state.
Summary: popup windows open in max state → popup windows open maximized
*** Bug 66799 has been marked as a duplicate of this bug. ***
shouldn't we be trying to get this checked in on the branch?
QA Contact: claudius → jrgm
It is drawing late for the 0.9.4 branch, but it probably should go on the 
"post-branch" branch.
Keywords: nsbranch
Blocks: 99194
Based on the comments in the bug. This looks like a good nomination. Marking as
nsbranch+. Let's get the SR and A as soon as the branch is cut!
Keywords: nsbranchnsbranch+
I'm closing (fix was checked in on the trunk yesterday) and removing the branch 
nomination. My comment from 2001-09-10 12:23 still applies. This bug hasn't 
appeared on the 0.9.4 branch and won't unless my fix for bug 96475 (not 96745 as 
I said above) is copied there. There's already a note in that bug to bring over 
this bug as well.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Keywords: nsbranch+
Resolution: --- → FIXED
*** Bug 99694 has been marked as a duplicate of this bug. ***
*** Bug 99707 has been marked as a duplicate of this bug. ***
v
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.