Closed Bug 74940 Opened 23 years ago Closed 16 years ago

Need to implement support for minimum window size.

Categories

(SeaMonkey :: UI Design, defect)

defect
Not set
major

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 357725
Future

People

(Reporter: mozilla, Unassigned)

References

Details

Somehow, I managed to get a mozilla window to be two pixels wide. Besides being
almost impossible to see, it was impossible to get mozilla browser windows back
to sane sizes again. By hacking the localstore.rdf file, I reset the window to a
sane size and was able to resize it, however, Mozilla enforce a minimum sane
size on windows so that it is possible to manipulate them.
what version of mozilla are you using? sounds like a localstore.rdf corruption issue
Fizzilla 0.8.1. The localstore.rdf file looked fine other than the messed-up 
window size. Shouldn't matter anyways; sanity checks still ought to be performed 
where feasable.
over to pinkerton for a look.
Assignee: asa → pinkerton
Status: UNCONFIRMED → NEW
Component: Browser-General → XP Apps
Ever confirmed: true
-> danm
Assignee: pinkerton → danm
should check to ensure windows fit in the current monitor(s) region too.
Target Milestone: --- → mozilla0.9.2
*** Bug 79005 has been marked as a duplicate of this bug. ***
Depends on: 79005
Clarifying summary to avoid dups.  We need to ensure that windows cannot be
opened or resized to the point that they cease to function as windows.  User
must always be able to recover from resizing by resizing back.  Note that some
platforms (e.g., Mac OS) may have guidelines for minimal window size that are
more restricive than this.  IMO, it would be good if we could facilitate
compliance with these guidelines (i.e., do the 'right thing' by default) without
overly restricting applications on other platforms 
Summary: Window too small, can't resize → Need to implement support for minimum window size.
*** Bug 79005 has been marked as a duplicate of this bug. ***
Whiteboard: OSX
*** Bug 79884 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla0.9.2 → mozilla1.0
Is this OS X specific?  I don't think it is
*** Bug 106925 has been marked as a duplicate of this bug. ***
Bug 79005 and bug 79884 are both OS: All.
Modifying platform/OS



OS: MacOS X → All
Hardware: Macintosh → All
Whiteboard: OSX
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
Target Milestone: mozilla1.0.1 → ---
Target Milestone: --- → Future
Keywords: mozilla1.0, oeone
Blocks: 109150
Bug 176320 has all the documentation about the summary of this bug.

One problem about minimal window sizes is that previous documentation provided 2
different ways specifying minimal sizes, where complying with/in one way could
allow to disrespect the other way. With 100px as minimal value for inner*
properties and with 100px as a minimal value for outer* properties, the obvious
problem, even happening in NS 4.x, is that a perfectly valid value for, say,
outerHeight could create a window where its innerHeight value would be under
100px... because of many requested toolbars, e.g.:

window.open(strURL, "",
"outerWidth=400,outerHeight=130,menubar,toolbar,personalbar,status"); 

will definitively create a short window where the innerHeight will not comply
with the minimum of 100px.

Same phenomenon with resizeTo(): parameters of this method could be meeting the
requested minimal values of outer* and, at the same time, violate the minimal
values of inner*. But the code never checks for this and never makes corrective
adjustements to comply with both ways.

resizeTo(400,130);
will resize such window to under minimal innerHeight value and, at the same
time, above minimal outerHeight values.

I explained in comment #5 of bug 176320 that there should be only 1 way of
defining the minimal size values of a popup window: with inner* properties, so
that there would be no conflict, no contradictory behavior, no awkward incoherence.

One last example:
window.open(strURL, "", "outerWidth=300,outerHeight=200,status");
will render a popup with a statusbar but the security padlock icon won't be
visible nor accessible *in any normal way* and the window resizing grippy won't
be visible nor reachable. Absence of menubar, scrollbars, resizability makes the
window frustrating to use.
Updating severity to major - when this happens (2x2 window size in
localstore.rdf) a typical user can't use Mozilla anymore (they don't know to go
whack localstore.rdf).

I haven't seen this myself in quite a while, but there was a recent complaint on
the newsgroup:
http://groups.google.com/groups?dq=&hl=en&lr=lang_en&ie=UTF-8&safe=off&selm=SQska.105769%24OV.209172%40rwcrnsc54

Removing circular dependency on bug 79005.
Severity: normal → major
No longer depends on: 79005
Product: Core → Mozilla Application Suite
Assignee: danm.moz → nobody
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
No longer blocks: 306681
You need to log in before you can comment on or make changes to this bug.