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.