Closed Bug 101509 Opened 23 years ago Closed 16 years ago

Pref to disable resizable=no

Categories

(SeaMonkey :: UI Design, enhancement)

Product:
SeaMonkey
Component:
UI Design
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME
Milestone:
mozilla1.7alpha

People

(Reporter: uamjet602, Assigned: vdvo)

References

Details

(Keywords: access) 

I would like a preference setting so javascript popups can no longer have a
fixed size. After all it is my desktop they are occupying, not the scripter's.

This probably would be a violation of the dom, but so is disallowing window.open
.Something like:

[x] Allow popup windows created using Javascript to be non-resizable
Over to dom0.
Assignee: rogerl → jst
Component: Javascript Engine → DOM Level 0
OS: Linux → All
QA Contact: pschwartau → desale
Hardware: PC → All
Hmm... this has two angles to it:

1)  The browser ui uses resizable=no.  That means that we would have to make a
    distinction between chrome open() calls and non-chrome ones.

2)  Can pref stuff be reasonably used in nsWindowWatcher?  Or would that be an
    embedding nono?
Is there a good reason for the browser ui to use resizable=no?

IMHO all dialogs should be resizable.
Future.
Target Milestone: --- → Future
See also bug 143886, pref to ignore window.open flags.
Why make it a pref?  If the user tries to resize a window, he usually has a
reason, such as the contents not fitting with his chosen font size.
Blocks: 86195
Dupe of bug 107949 which is more general?

pi
No, because this could be implemented completely independently and is a much
more serious accessibility problem, imo.
Depends on: 107949
Keywords: access
> IMHO all dialogs should be resizable.

I don't disagree, but that would IMO be a window manager 
or OS issue.  Let's keep this bug about what _websites_
can prevent the user from resizing.  (Unless there's an
accessibility issue with browser-generated dialogs when
the user uses a larger font than usual or something...
but I am not aware of any such issue.)

Regarding bug 107949:  that's more general; I can see 
it depending on this, but I don't think it's a dupe.  

Regarding comment #6:  I think it needs to be a pref.
When a poweruser resizes a window, it's for a reason;
when some endusers resize a window, however, it might 
be a mistake.  (Many inept users are not aware that 
windows can be resized by any means other than the 
maximise button.)  I think it's acceptable to require 
powerusers to turn on a pref once to get the ability 
to resize things that the website thinks they shouldn't.  
There should be a UI for it in Scripts & Windows, 
however.  Not all powerusers are comfortable with prefs.js

The backend work for this was done in bug 107949 and can be prevented with a
hidden pref (see the patch in that bug for details)
> When a poweruser resizes a window, it's for a reason; when some endusers
resize a > window, however, it might be a mistake.

If a user accidentally resizes a javascript-generated window, it's not
devastating.  In fact, it's less likely to cause problems than if the user
resizes a window he opened himself, because Mozilla will remember the new size
if he opened the window himself.
There is a pref for this now:

user_pref("dom.disable_window_open_feature.resizable", true);

Is this bug about adding UI for it? Or should it be turned on by default?
The last question is still unanswered. WFM?

pi
The initial report explicitly called for a user-settable pref.  What we have
right now does not really fit that definition yet.  Yes, it needs UI.  Over to
XP Apps to do that.
Assignee: jst → sgehani
Component: DOM Level 0 → XP Apps
QA Contact: desale → paw
Target Milestone: Future → ---
qa --> sairuh@netscape.com
QA Contact: paw → sairuh
This one is probably mine.
Assignee: sgehani → caillon
Target Milestone: --- → mozilla1.2alpha
*** Bug 155531 has been marked as a duplicate of this bug. ***
*** Bug 162618 has been marked as a duplicate of this bug. ***
Blocks: useragent
No longer blocks: 86195
Summary: [RFE] Pref to disable resizable=no → Pref to disable resizable=no
See also bug 177838, which asks Mozilla to ignore resizable=no by default.  The
reporter of 177838 mentioned that Opera ignores resizable=no.  I think we should
fix 177838 but not add UI for the pref.
Re: comment #6: 
>If the user tries to resize a window, he usually has a reason, such as the
contents not fitting with his chosen font size.
Re: comment #9
>when some endusers resize a window, however, it might 
be a mistake.  (Many inept users are not aware that 
windows can be resized by any means other than the 
maximise button.)
Even if the user had no particular reason, in which manner would preventing the
user from resizing his browser window promote his web experience? If the user
likes a window to be a particular size - whatever the reason here -, then he
should be able to resize his browser window. The web designer has 100% control
and power over the content. The user should have a veto and a final word on the
settings involving the chrome and the normal, standard functionality of his
browser windows.

In bug 177838, I submitted that ignoring resizable=no should be a normal
feature, a standard feature in Mozilla. I even tested this idea in newsgroups.
Overall more experienced people agreed I would say; younger and more controlling
people disagreed. They want the user to see their website exactly the way they
see it.

If you make this resizable=no as a setting, then people will be furthermore
confused, I would say; already people over-exaggerates and over-expects what
unchecking the "Open unrequested windows" checkbox do.

This resizable=no thing is among a large bag of matters which over the years
have made the overall mass of users become reticent, hesitant, suspicious about
javascript. Windows in almost all possible windows-based applications are always
resizable... but not on the web. That's really sad.

"The safe and most flexible option for both sides (author and users) is to make
the window always resizable, at any time: nobody can be sure that this 100x100
or that 200x200 window will suit the user's taste for x, y or z reasons. I do
not see how the author's interests are best served by taking a chance of
irritating the user with an incorrectly sized window. 

IMO, it is in the best interests of both the users and the authors to always
allow the users to resize popup windows at any time according to his tastes, his
viewing habits, his needs, etc... "
Opera 7 beta 1 also ignores resizable=no. It might be that they never had time
to think about implementing this "feature" or time to implement this window
feature. Maybe they have thought this over: giving the content developer the
ability to remove a functionality in a browser window on the user side does not
strike immediately as adding any kind of value or content to such window in the
first place. 

Anyway, I don't like to resort to a typical argument which goes "Browser_X,
browser_Y and ... has this feature/option/setting, so should we." I think any
feature, option, setting should be carefully thought up in the first place and
then implemented because it adds value to a browser.
I'd like to disable all restrictions on resizing including the NORESIZE frameset
tag and to be able to view any toolbars that have been disabled.
Re: comment 22;
Dan, your comment per se has nothing to do with this current bugfile although I
want you to know that I understand your perspective. You may want to have a look
at bug 60323, bug 86194 and bug 177838. Regarding bypassing the NORESIZE
attribute of frameset, I do not know if there is a bugfile on that.
Your request for the ability to view any toolbars that have been disabled must
only point toward secondary popup windows. There is already bug 75158. Titlebar
and statusbar are already into the user's side/control.
There is bug 176304 (Phoenix branch) which would meet exactly your wishes. If
you use a recent build of Mozilla, then you can for now just add this in your
user.js and you'll get all the chrome bars you wanted:

user_pref("dom.disable_window_open_feature.menubar",     true);
user_pref("dom.disable_window_open_feature.toolbar",     true);
user_pref("dom.disable_window_open_feature.location",    true);
user_pref("dom.disable_window_open_feature.personalbar", true);
user_pref("dom.disable_window_open_feature.scrollbars",  true);
user_pref("dom.disable_window_open_feature.resizable",   true);

I use this and enjoy popups nowadays. Other chrome bars (tab bar, Site
Navigation bar) are dependent on other bars; statusbar can be controlled via the
advanced/Scripts & plugins settings.
> Regarding bypassing the NORESIZE attribute of frameset, I do not know
> if there is a bugfile on that.

Already implemented. Set layout.frames.force_resizability to true.
Blocks: 170454
> Even if the user had no particular reason, in which manner would 
> preventing the user from resizing his browser window promote his 
> web experience?

By reducing confusion.  I'm talking about extreme hardcore end users
here, people who accidentally resize things and don't know what they
did or how they did it or why (whatever) is now messed up, people who
think pushing the mouse button down is clicking and don't understand
dragging at all.  Such people would be impossibly daunted by changing
any preferences, so you set the default prefs for their benefit and 
then allow slightly more clueful people to change some prefs.  Of 
course, the people I'm talking about also won't be installing Mozilla
builds per se, but they might end up with an ISP branded release if it
comes with an internet connection kit.  The ISP doing the branding can
presumably change the defaults, but the prefs have to exist.  And if
you want more clueful users to be able to change them back easily,
they need a UI.  See simple chart:

defaults (in Mozilla)  |  unimportant; we all know how to change them.
defaults (branded)     |  for end users
prefs UI               |  for power users
prefs.js et al         |  for developers

This is an oversimplification, but it is a useful one.  I think that
explains why I think this should have a UI, even if we turn it on by
default.  It's not because I think many users will turn it off.
Jonadab: the vast majority of browser windows can be resized.  I think letting
some pop-up windows be non-resizable increases confusion overall, even for
relatively inexperienced users, because many of those users know how to resize
windows.  Furthermore, if you don't know how to resize windows, accidentally
resizing a pop-up window is much less problametic than accidentally resizing a
normal browser window (resizing a normal browser window is permanent).

I don't understand your argument for why this should have pref UI regardless of
the default value of the pref.  It sounds like you're saying "some distributors
might set an unreasonable default value for this pref, so the pref should have
UI."  I think it's unlikely that a distributor will want the unreasonable
default value and also want UI for the pref.
Target Milestone: mozilla1.2alpha → mozilla1.5alpha
*** Bug 210964 has been marked as a duplicate of this bug. ***
Taking, though I may be a bit optimistic. ;-)
Status: NEW → ASSIGNED
Target Milestone: mozilla1.5alpha → mozilla1.7alpha
Oops, I thought "Accept Bug" would set me as the assignee. Really taking now,
hopefully.
Assignee: caillon → vdvo
Status: ASSIGNED → NEW
Is it out of the question to make the pref default to true (i.e., disable
resizable=no), hopefully satisfying bug 177838? I'd prefer that, because I see
no valid reason for non-resizable windows (I don't buy the less-confusion
argument), so if the capability must be there in the first place, I'd like it
turned off by default.
Brendan, what say you? I'm personally in favor of adding a pref for this, and
letting it default to true (i.e. not supporting non-resizable windows at all)
since I don't think I've ever seen a window that would in any way benefit from
being non-resizable.
jst, the pref is there:

http://lxr.mozilla.org/mozilla/search?string=open_feature.resizable

We just need to flip it for all the apps.  Cc'ing bugs, I mean Ben, and I'll
mail him this bug to get his response.

/be
While I support making it such that web page opened windows can't be
non-resizable... I completely and resoundingly reject the notion that all UI
windows and dialogs should be resizable. I will reject any code that that
controls FE windows' resizability that lives below the front end line (i.e. that
affects all front ends, Seamonkey, Firebird, Thunderbird etc) and is defaulted
to ignoring the "resizable" flag. 
Let me clarify. SOme web pages size windows for how their content will appear in
IE, or just size it poorly. The level of trust I have for random web developer X
is not that high. Resizable windows in this case is good. 

With the FE, I almost always know what *I* am doing, and select window open
flags carefully. If people feel certain windows should be resizable, than that's
either a bug, or they're crazy. (e.g. I don't want alert messages to be
resizable, that's just insane). 
Yeah, agreed, I should've clarified in my comment as well that I was talking
about non-dialog windows opened by webpages.

Seems like we need to make the pref checking code in nsWindowWatcher.cpp only
check this (or all prefs) if opening dialogues to get the desired behaviour (or
does it already?), anyone interested in writing up a patch, or should I?
jst: go for it -- content only, chrome can still say resizable=no.

/be
Note that my opinion that any window (including frontend) should be resizable
was just a rebuttal to comment #2.

It never was what I meant with this bug. If I want to, I can probably coerce my
window manager to make any window resizable.

As far as I'm concerned this bug is fixed.
I can't find any dialogs in Mozilla that are not resizable, and I have
dom.disable_window_open_feature.resizable=false. Can someone give me an example
of a dialog in Mozilla that is currently not resizable?
javascript:alert(1) is not resizable.
(In reply to comment #39)
> javascript:alert(1) is not resizable.

I thought it shouldn't be, but it is. I'm using a current build of Mozilla on
Debian Sarge in KDE 3.1. I'm pretty sure I've seen non-resizable windows (so I
don't think it's a problem of the window manager), but all Mozilla's windows
seem to be resizable. Any idea?
> so I don't think it's a problem of the window manager

Sure it is.  We set the "non-resizable" hint on the window (and fvwm, eg follows
it).  If your WM does not, it's your WM's fault.
I tried on Windows and indeed, javascript:alert is not resizable but becomes
resizable when dom.disable_window_open_feature.resizable is set to true. (Not
before a restart of Mozilla, though - it seems it's another of those prefs that
are only read once and don't install a pref change listener.)
Please implement this as option(!) in "Advanced JavaScript Options"! Some users
want to keep non-resizable windows non-resizable because resizing often only
leads to bad scaled content.

I think this should be an switchable option (like it is already possible to
switch on/off allowing websites to disable the context-menu).

I have submitted bug 259190 therefor.
(In reply to comment #43)

Sorry, I mean Firefox. But nevertheless in Mozialle Suite it should also be an
option.
Product: Core → Mozilla Application Suite
A preference needs to be added for this option.  "Some users don't know how to resize windows" is an invalid excuse, unless you make all Firefox windows ever unresizable.
Is this still relevant now after bug 177838 has been fixed?
Since bug 177838 has been fixed, this bug is no longer relevant.

Resolving as WORKSFORME
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.