161903 - [RFE] Add pref for ignoring window size options on window.open() (minimum/maximum)

Status: RESOLVED INACTIVE

(Core :: DOM: Core & HTML, enhancement, P5)

Description

[Hanspeter Niederstrasser]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1b) Gecko/20020722
BuildID:    Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1b) Gecko/20020722

This is an expansion of Bug 107949.  Bug 107949 sets preferences for what window
chrome can be hidden/shown when using window.open().  However, it does not
establish a preference for how small/big that window can be.  If resolved, this
bug will fix that.

Reproducible: Always
Steps to Reproduce:
1. Open an extremely large/small window via window.open() (see URL for example)
2. The window opens to the dimensions set inside the window.open() call.

Actual Results:  Window always opens with dimensions set in window.open().

Expected Results:  With the proposed preference set, a window.open() window must
fit within certain user-defined dimensions.

Note that this is not a pref to allow resizing of the window (Bug 101509, Bug
107949). This is to define the dimension limits of the spawned window.

Comment 1

[snebeling]

Related: bug 118717.

Comment 2

[R.K.Aa.]

see also bug 102362 comment 2

Comment 3

[Hanspeter Niederstrasser]

The URL for this bug is actually the testcase attachment for Bug 118717, as it
opens a purposely large window.  Also related is Bug 84754, but neither one
deals explicitly with setting user defined size limits for spawned windows,
hence this bug.

I'm envisioning a preference set for this bug along the lines of:

pref("dom.disable_window_open_feature.min-width", "#");
pref("dom.disable_window_open_feature.min-height","#");
pref("dom.disable_window_open_feature.max-width", "#");
pref("dom.disable_window_open_feature.max-height","#");

If the dimensions used in window.open() fall within the dimensions set in the
relevant preference, then the window spawns to those dimensions.  If an author
dimension falls outside its user defined range, then that dimension is changed
to the appropriate limit.

Comment 4

[Jesse Ruderman]

See also:
bug 55696 RFE: "Open a JavaScript link in a new window"
bug 64560 turn window.open into a normal link

With those bugs fixed, you would be able to left-click a window.open "link" to
follow it as a normal link, or middle-click it to open it in a new window of the
correct size.  I think that would make more sense than adding a set of hidden
prefs for what size a window.opened window can be.

Comment 5

[Hanspeter Niederstrasser]

Re: comment #2
This bug is about the allowed dimensions when opening a new window, not for
changing the dimensions of an already opened window (bug 102362).

Re: comment #4
In those cases, the fixes would affect how the window.open link works, that is:
does the window get opened as a normal browser link (such as when you click a
plain vanilla "href=http://" link) or as the author defined popup window.  This
bug allows for an author-suggested, user-limited popup window.

> to open it in a new window of the correct size.

In some cases, the 'correct' size for the popup does not work on a user's
monitor: such as a 1200x1200 window on a 1024x768 monitor or a 100x100 window on
a 1600x1200 monitor.  This preference would then allow the user to say _a
priori_ for example: never make a window that's smaller than 300x200 or bigger
than 800x600.  The popup window would still happen as a popup window, but the
dimensions would have to be within the user defined ranges.

If the user decides to have javascript links be opened as normal links, that
setting would obviously take precedence, but when that setting is not turned on,
controlling the resulting popup dimensions should be made possible, just as bug
107949 controls what chrome a popup window can remove.

Comment 6

[Vidar Haarr (not reading bugmail)]

 -> DOM Level 0 (or should it be XP Apps ?)

Comment 7

[Johnny Stenback (:jst)]

Future for now, if someone wants to work on this now, feel free...

Comment 8

[Gérard Talbot]

If I understand the idea of this RFE bug, the web developers have the
sizeToContent() method. Now the users should have a 
Scripts & plugins/Allow scripts to:/fit within reasonable limits 
setting as well in order to avoid awkward sized popup distortions, illogisms.
Interesting idea. These limits would have to apply only to the content area
(innerWidth/width, innerHeight/height; not to the outerWidth/outerHeight
dimensions). 
Anyway, right now, the minimal 100x100 limit does not even apply to the content
area. The max. dimensions values usually (not always!) comply, respect the
screen.availWidth/availHeight values. 

http://jibbering.com/du/MozPopupHelpTestcaseDebugger.html

Comment 9

[Hanspeter Niederstrasser]

That is correct.  Popups larger than the monitor resolution[1] are illogical. 
They can also be bothersome at higher resolutions.  The converse is also true
(small window on a very high res monitor).  So the user could then set
prefered/reasonable window dimension _limits_.

I don't know what limits are already built in.  [1]Apparently the window open
'parser' limits the window to the availWidth/Height amounts and there's also a
minimum size (150px?).

This RFE would complement those in case the user wants a narrower set of
available dimensions.

Comment 10

[Daniel Wang]

*** Bug 135986 has been marked as a duplicate of this bug. ***

Comment 11

[Johnny Stenback (:jst)]

Mass-reassigning bugs to [e-mail]

Comment 12

[Felix Miata]

adding "minimum/maximum" to summary to make search more likely to hit this

Comment 13

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.