179711 - Implement sizeToContent as a UI preference setting for secondary child [popup] windows

Status: RESOLVED WONTFIX

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

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


Allow the user to constraint all secondary child [popup] windows to be
[re-]sized to fit the content of the document. Such setting would bypass,
override, overrule, veto the author's specific dimension size values
(outerWidth/outerHeight, width/height and innerWidth/innerHeight).

1- No scrollbars, no scrolling unless the document overflows, exceeds the
screen.availWidth/screen.availHeight value(s)
2- No doubtful tricks, no deceitfulness, no waste of time
3- The author can start expecting this feature, this user setting/option
preferences in his design, planning.
4- The user no longer has to worry, bother about ridiculously small windows nor
about unnecessarly large windows. Peace of mind.
5- People with physical and/or eye disabilities should be relieved a bit.
6- The user can still turn off 
Edit/Preferences.../Category:Advanced/Scripts & plugins/Allow scripts to:/Move
or resize existing windows
and prevent authors from toying, fooling around with secondary child popup windows.
7- The user and author are no longer focusing on a strategical battles involving
chrome UI elements or normal, standard browser functionalities but are now
invited to both focus, switch toward content issues. Peace of mind. It is in the
best interests of both authors and users to be able to access a window's content
without annoyances, worries, delays or difficulties.

Reproducible: Always

Steps to Reproduce:

Comment 1

[Boris Zbarsky [:bzbarsky]]

How does one tell that a window opened via windows.open() is a "popup" as
opposed to just a full-size window?  Should this only apply if the site tries to
set width/height explicitly on the new window?

Comment 2

[Gérard Talbot]

>How does one tell that a window opened via windows.open() is a "popup" as
opposed to just a full-size window?
I do not know specifically, but here's a clue, hint to start with. A secondary
child [popup] window always has an opener [parent] window, a reference to its
opener. When a javascript tries to close a non-window.open() window, a security
warning pops up, is triggered indicating that a script is trying to close the
window. So, internally, the browser must know how to distinguish, how to
recognize, how to know somehow/to tell them apart 
- which windows were opened by a parent with still an opener reference and 
- which windows have no opener, were not opened by another window.open() call,
were "1st ancestor" (if I may used such expression).

>Should this only apply if the site tries to set width/height explicitly on the
new window?
No. Not exclusively. Such setting, active preference would be applied even when
the author does not give specific size in his window features list parameters.
It would rule/overrule/override over any/all specified, requested size dimensions.
E.g.#1:
 _
IxI <-- (checkbox checked)
 -   Automatically set the size of secondary [popup] windows so that they fit
their content

var WindowReference;
function OpenPopup(strURL, strWindowName)
{
WindowReference = window.open(strURL, strWindowName,
"left=300,top=200,width=369,height=472,status=yes,scrollbars=yes");
}

and the values 369 and 472 would be overruled, ignored as the browser would
determine itself what are the most compact, minimal, optimal width and height
content dimension sizes for the popup. Whatever the author would indicate as
specific dimensions sizes for the popup window 
(for content area: width/height, innerWidth/innerHeight; 
for chrome dimensions:outerWidth/outerHeight; 
for fullscreen: fullscreen=yes), 
they would *all* be ignored and the browser would determine such dimensions
sizes according to the sole criteria of fitting best, in the most minimalist,
compact manner the content of the document. The browser would always act as if a
WindowReference.sizeToContent() method was called within/during the process of
rendering the window.

E.g.#2:
 _
IxI <-- (checkbox checked)
 -   Automatically set the size of secondary [popup] windows so that they fit
their content

var WindowReference;
function OpenPopup(strURL, strWindowName)
{
WindowReference = window.open(strURL, strWindowName,
"left=300,top=200,status=yes,scrollbars=yes");
}

Finally, as stated, it would overrule, override, "veto" over fullscreen=yes.

In many ways, if such setting is doable, it would bridge the gap of deafness and
suspicion/irritation between author and user on the usability and accessibility
domains. The user would "throne" again over his domain: the chrome UI elements
and the normal, browser functionalities. The browser would be "domesticated",
tamed to fit, suit in the automatic manner the user's most understandable, most
normal expectations. Again, it is in the best interests of both users and authors 
- to give the authors and users the best chance of some use to all such popups
without lost of time, resizing, irritation, giving a furthermore bad reputation
to javascript, etc.
- to be able to have a good "first" normal access to the content of the popup,
- to meet/relate to each other on the bridge on reasonable access to content
- no scrollbars would appear on such first-rendered popup windows unless the
content of document would exceed the screen.availWidth/screen.availHeight values

(I'm more or less repeating the same arguments I listed in bug 179704 here)

Such setting would not prevent the user from turning on or off the power of
"Move or resize existing windows" to the author. Such setting would not prevent
nor hamper the user from resizing himself the popup window as he wishes, at the
dimensions he would prefer. Again, full control, full latitude, full freedom to
the user here.

By giving the last word, the initiative to the user, the browser setting will
first sterilize, neutralize, avoid, prevent irrational, unreasonable dimension
requests from the author. The most stubborn controlling web authors will have to
take such user prefs setting into consideration and to adapt to the new
situation. Hopefully, both authors and users will focus on web content and not
on over-excessively controlled dimensions of chrome or on normal browser
functionalities. Hopefully a new "game" around content will take place between
authors and users, not a strategical "war" where both just lose time, energy,etc..

Comment 3

[Boris Zbarsky [:bzbarsky]]

Please stop repeating the same thing 5 different ways.  It does not help.

Did you even read my comment?  Based on "A secondary child [popup] window always
has an opener [parent] window", I am guessing no.  Because both popup and
non-popup windows have an opener.  Specifically, how should behavior be
alike/different in the following two cases:

window.open("http://foo");
window.open("http://foo", "", "width=300,height=300");

imo, in the second case it would make sense to sizeToContent() while in the
first case that would be utterly pointless.

Comment 4

[Gérard Talbot]

> Because both popup and non-popup windows have an opener. 
I did not know that. How does the browser arrives to know when to send a warning
about a script trying to close the window then? Internally, the browser must
know how to tell them apart.

>in the first case [window.open("http://foo");] that would be utterly pointless.
Why is that? Isn't it a reduced form of my own e.g.#2 here? Why the generated
popup window should not be resized to fit the content of "http://foo" if this is
the wish of the user?

Comment 5

[Boris Zbarsky [:bzbarsky]]

> how when to send a warning

We would send such a warning for any window with no opener.  The issue there is
not popup or not but created by the web page or not.

> Why is that?

Because a popup (with width and height set) generally has a certain amount of
content to be shown in it and that's it.  In contrast to this, a window which is
opened with no width/height set is usually meant to take the user through a long
series of pages, with different amounts of content in them. So resizing it based
on the first of these pages (from the user's _preferred_ size for normal browser
windows) makes no sense.  Resizing on every page change also makes no sense.

Comment 6

[Gérard Talbot]

I do not know if Mozilla can tell apart a window created by a web page from a
window created by typing an url in the locationbar or by a click on a bookmark 
(and to do this in a reliable manner). And if so, how Mozilla does it. I agree
with you that this is a very important question for this enhancement request. 

>a window which is opened with no width/height set is usually meant to take the
user through a long series of pages, with different amounts of content in them.
I understand now what you had in mind. There is no way an user setting prefs can
figure out the intent, purpose or eventual usage of a created window. There is
no "smart" setting which will always suit the users here and adapt constantly
itself intelligently to different site designs. How solid, reliable is this
custom, practice of no width/height set for long serie of pages of different
amount of content? Impossible to tell. No idea.
In my experience, most of the time, generated window do not even have a location
bar, no menubar, no personal bar so no entering an url and no possibility of
clicking a bookmark.

> resizing it based on the first of these pages (from the user's _preferred_
size for normal browser windows) makes no sense.
Well, it would certainly size the first page accordingly. Other following pages,
if any, might not fit at all: that's likely to happen.
I agree that "Resizing on every page change also makes no sense." In my mind,
this sizeToContent user prefs should be a one time feature applied to a created
window via the open() method.

I agree with you that my enhancement proposal has to work out such scenarios.
But I can already say with certainty that there is no user prefs setting right
now which is ideal for the users. I just think that users should be able to get
assistance from the browser so that generated opened window have the least risks
of alienating the users.

Fair enough?

Comment 7

[Boris Zbarsky [:bzbarsky]]

Lack of a menubar is irrelevant. That's what links are for.  As I said, the
intent of a window can be very clearly seen from whether it's being forced to a
given size.  If it is, it is not meant to be a window actually used to look at a
series of pages and then we should feel free to ignore the site author and
sizeToContent().  But ignoring the _user_preference_ in the other case is
unacceptable, imo.

Comment 8

[Gérard Talbot]

My surf experience is that 90% of sites using popup do it by focusing a lot on
constraining, limiting, "funneling" the users (window options, setting, sizes,
etc). They do it without thinking, by first turning off menubar, location bar,
etc... which could be used to get out of the author's predefined scenarized
chain of pages.
Menubar could be used to restore location bar (via View/Show-Hide) and also give
access personal bookmarks; that's 1 reason why authors almost always turn this off. 
When I first presented this enhancement, I wanted this setting to be applied
unconditionally to any/all popup generated with the open() call, and this,
without any complex, difficult exceptions, without any "if author does, then...
except if..., otherwise" complex guess path. 
Such UI setting can not guess in advance the intent of the author nor should it
assume of the intent/goal of the author when he does not set predefined sizes:
nothing is forced. You would be surprised at how badly designed some sites using
popups are.

If no sizes are given, then the setting should presume, assume a long serie of
linked pages? I say this is not an assured custom and this cannot be forced. And
even if it was, then this setting would have to be applied sometimes, not
always, under some precise conditions (sizes given or not) ... which would
furthermore create confusion in the users' mind. So I agree with you that
"ignoring the _user_preference_ in the other case is unacceptable".