179704 - Implement sizeToContent as a window feature, a window option in the window.open() method

Status: RESOLVED WONTFIX

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

Description

[Gérard Talbot]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021108
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021108


This enhancement would allow an author to size perfectly a secondary child popup
window to the content without bothers or worries. The idea is to allow such
option before a particular user setting could prevail regarding the method
WindowReference.sizeToContent(). 

If the user has set, has UNcheck the checkbox
Edit/Preferences.../Category:Advanced/Scripts & plugins/Allow scripts to:/Move
or resize existing windows,
then the recourse to the sizeToContent() method is useless.
Allowing a "sizeToContent=yes" as an option, as a feature in the window features
list would allow the author to solve at least 2 problems: 
1) figuring out the ideal, optimal, minimal, most compact size of the window
(without scrollbars) for the content and its entire view
2) how to avoid being caught by the user prefs setting regarding resizing an
existing window.

sizeToContent as a window feature would not be turn on by default. sizeToContent
would be spelled exactly like the method without "()"; that way, no need to
boggle the mind unnecessarly. sizeToContent=no would simply tell the browser to
ignore this option: sizeToContent=no would do nothing.

-------------

E.g.:
var WindowReference;
function OpenPopup(strURL, strWinName)
{
WindowReference = window.open(strURL, strWinName,
"screenX=300,screenY=100,sizeToContent=yes,menubar=yes,scrollbars=yes");
}

Here, width/height or innerWidth/innerHeight or outerWidth/outerHeight are not
given: sizeToContent should prevail and work like a
WindowReference.sizeToContent() call would work.
Here, scrollbars=yes would be irrelevant, would achieve basically nothing really.

---------------

E.g.:
var WindowReference;
function OpenPopup(strURL, strWinName)
{
WindowReference = window.open(strURL, strWinName,
"screenX=300,screenY=100,sizeToContent=yes,outerWidth=400,outerHeight=200,menubar=yes");
}

Here, outerWidth/outerHeight requested values would be ignored and the popup
window would be built as if a WindowReference.sizeToContent() call had been
made. In any/all cases where size dimension values would be
specified/given/requested by the author, then sizeToContent=yes would bypass,
would have the veto, the precedence over the requested sizes.

The author can/would still nevertheless have lots of freedom when planning his
popup windows. He could add, increase, decrease margins, padding on the html
and/or body element; he could make a span, a paragraph non-breakable, thus
making deciding, determining in advance the width of the window.

A lot of sites based on/made with thumbnails and [enlarged] popup images would
be simplified.

The underlying global idea behind this enhancement request is to bring a bit of
relief to both authors and users as the browser can take over such dimensioning
task. The underlying global idea behind this enhancement request is also to
incite, entice, invite both authors and users to "worry" about content, to focus
on content, not on browser functionalities, not on "perfectly" thought up
measurements of all sorts, not on tricks or doubtful effects, not on
deceiptfulness, etc..


Reproducible: Always

Steps to Reproduce:

Comment 1

[Boris Zbarsky [:bzbarsky]]

to danm

Comment 2

[Jesse Ruderman]

So the pop-up window wouldn't appear until the *remote content* in the window
has finished loading?  I'm worried that a sizeToContent window.open feature
would make web sites less responsive for many users.  Some web developers
wouldn't notice the change in responsiveness due to having fast computers, fast
connections, and local copies of the web site.

Comment 3

[Gérard Talbot]

Re comment #2: I agree with what you say. This is a problem indeed: 
- processing content first
- then determine optimal window sizes
- then laying out window 
will take additional time... don't see how this could be prevented.

My idea was how such good feature could sneak in front of the user prefs "Allow
scripts to:/Move or resize existing windows" before such user setting would
prevent web developers from using the sizeToContent() method.

Maybe this idea cannot work out...

Comment 4

[Gérard Talbot]

If you look at bug 176320 and at attachment 105780 [details], you'll see that the
application needs to figure out anyway the inner dimensions of the popup window
to be at some point and then make proper adjustement (if needed). This is
necessary when innerWidth/innerHeight (or width/height) are not specified; when
outerWidth/outerHeight only are specified.

So, code-wise, bugs 176320 and 179704 are related as the application needs to
figure out first if the given values meet requirements.

Comment 5

[Dan M]

Unless I misunderstand, which is way possible, the problem described in bug
176320 is a problem with the size of a window's chrome. Assuming all chrome is
local (not downloaded from a server at runtime) that calculation can be
performed before downloading remote content. So that bug doesn't have the same
latency problem this bug has.

As Jesse noted, this bug requires waiting for content to finish loading before
sizing the window. That's a problem but I think it isn't a big problem. The
suggested feature is optional. As a website author, you'd choose to size your
windows to content only if you didn't mind the delay. Speaking from (some)
experience coding chrome windows and small websites, generally the kind of
window one wants sized to content is a window that's small on chrome, big on
content. By that I mean that such a window is pretty boring without its content
so it's reasonable to think that it's an uninteresting window before its content
has finished loading, so a delay while loading its content seems reasonable.

The problem I see with this feature is that it would work only in Mozilla. If
you want your website to work with -- sadly here we are -- the 99% of browsers
most likely to be used to visit it, you'll have to write the code to size your
window the old-fashioned way, as well.

Sizing to Content is a useful feature for chrome windows but I'm thinking not so
much for content windows. I'll keep the bug open, but I'm afraid it gets the
Future treatment.

Comment 6

[Jesse Ruderman]

> My idea was [to allow sites to] sneak in front of the user prefs "Allow
> scripts to:/Move or resize existing windows" [when the user has disallowed it,
> which currently prevents] web developers from using the sizeToContent() 
> method.

How about making separate prefs:
[ ] Allow scripts to move or resize normal browser windows
[x] Allow scripts to move or resize pop-up windows that don't have toolbars

The first pref could be hidden and default to off.  Since it would be limited to
normal browser windows, it wouldn't break many sites, but it would disable one
of the runners-up in the "most annoying thing that web sites do" list.  See bug
60323, "Don't allow JS in Web pages to resize my browser window, by default".

The second pref could be hidden if there were a pref to disallow sites from
opening windows without toolbars.  For example, there could be a pref to
disallow sites from making links open in new windows (bug 64560) or a pref to
make toolbars always appear in script-opened windows (bug 176304).

If the second pref is not hidden, Mozilla should ignore resizable=no (bug
177838), at least when scripts are disallowed from resizing pop-up windows.

Comment 7

[Jesse Ruderman]

Comment 6 -> bug 186708

Comment 8

[Serge Gautherie (:sgautherie)]

Filter on "Nobody_NScomTLD_20080620"

Comment 9

[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.

Comment 10

[Anne (:annevk)]

We don't want to support new popup functionality.