Closed Bug 101509 Opened 19 years ago Closed 12 years ago
Pref to disable resizable=no
Over to dom0.
Assignee: rogerl → jst
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.
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.
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.
> 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)
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 --> firstname.lastname@example.org
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. ***
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.
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.
> 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.
18 years ago
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?
> 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.
(In reply to comment #43) Sorry, I mean Firefox. But nevertheless in Mozialle Suite it should also be an option.
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: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.