Closed Bug 177838 Opened 22 years ago Closed 17 years ago

Make all popup windows resizable, ignoring resizable=no

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.9beta2

People

(Reporter: bugzilla, Assigned: dao)

References

Details

(Keywords: access)

Attachments

(1 file)

patch
1.38 KB, patch
sicking
: review+
jst
: superreview+
mtschrep
: approval1.9+
Details | Diff | Splinter Review 
Authors have the ability to turn off an important browser window functionality
in a secondary child [sub-window] popup window when editing the window.open()
method: with resizable=no in the window features list, they can prevent the user
from resizing the window to be.

I just think there is no possible good reason for doing so. Let's say the popup
window was sized to width=300,height=200. Let's suppose that these window sizes
fit perfectly the viewing conditions, habits, the taste of the users: then,
there is no damage, no irritation, "no harm, so no foul" here. But what if,
despite all the care and thinking of the author, the content does not fit well
within the popup window dimensions or the popup window sizes do not suit the
taste of the user(s) for whatever reasons here: then I do not see what the
author has accomplished, has achieved by preventing the user(s) from resizing
the window. 
When an author deprives his visitors from resizing the popup windows, then he's
removing from these browser windows one of their normal, standard browser
functionalities.

When an author goes
var WindowReference = window.open(strURL, strWindowName,
"width=100,height=100,resizable=no");

then the author is saying: "I'll create a secondary window (which will popup
over the current page) when the user clicks this link/button and I will prevent
him/her from resizing that child, secondary window for good. No maximize, no
resize possible, no kidding...". Is that reasonable? 

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

People can custom a stylesheet and then [!important] override the author's style
sheet. But an user cannot restore the normal browser window functionality which
he was deprived of: that makes no sense. One of the reason why popup windows
have a so bad reputation is because of years of abusive recourse to excessive
control over the users' normal browser functionalities.

Secondary windows are created so that they can be moved, resized, put aside
(minimized) for awhile so that they can be raised, brought up later.

Opera 6.x ignores "resizable=no" in the window.open() call and will make child
secondary popup windows always resizable.
 
References:
===========

setResizable(trueOrFalse)

A Boolean value specifying whether a user can resize a window:
    * true lets a user resize the window
    * false prevents a user from resizing the window

(...)
With the setResizable method, you can explicitly enable or disable the ability
of a user to resize a window. You can also specify whether a window is resizable
at the time you create it when you use the window.open method.

http://developer.netscape.com/docs/manuals/js/client/jsref/window.htm#1203720

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

open method
windowFeatures

resizable

If yes, allows a user to resize the window.

http://developer.netscape.com/docs/manuals/js/client/jsref/window.htm#1202832
See also bug 101509, which asks for a pref to disable resizable=no.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Make all secondary child popup windows always resizable despite the author request → Make all popup windows resizable, ignoring resizable=no
Blocks: useragent
No longer blocks: useragent
Blocks: useragent
Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs
Re: comment 1

Either this is a dupe, or this particular reporter wants the feature to be
hard-coded rather than an option.
"Earlier versions of Internet Explorer ignored the resizable=no feature and
allowed you to resize the new window."
http://support.microsoft.com/default.aspx?scid=kb;en-us;211068

So, MSIE 5.01 and previous were always ignoring resizable=no.
Opera 7.x always ignore resizable=no.

This is not a dupe and I want the window resizability to be enabled all the
time, always. No UI setting to find, to understand and to select, no resizing
grippy to implement and to debug, no user.js to edit, no knowledge base site to
read, no email to send to the webmaster, no posting in newsgroup and no
nonsensical efforts to do to restore normal and standard window functionality.
This bug has lain fallow far too long. FB and Moz now allow web designers to
dictate a fixed window size, without scrollbars or other controls. But if
someone uses larger system fonts for readability, the text will not fit in the
window. And sometimes web designers make mistakes and the fixed sizes are too
small even for normal text.

Moz and FB can be set so that they ignore the "no" commands. I got the user_pref
entries below from some help sites. They work--I've used them for more than a
year. They should be default for both browsers, but especially for Firebird.

Proposed defaults:

user_pref("dom.disable_window_move_resize", true);
user_pref("dom.disable_window_open_feature.close", true);
user_pref("dom.disable_window_open_feature.directories", true);
user_pref("dom.disable_window_open_feature.location", true);
user_pref("dom.disable_window_open_feature.menubar", true);
user_pref("dom.disable_window_open_feature.minimizable", true);
user_pref("dom.disable_window_open_feature.personalbar", true);
user_pref("dom.disable_window_open_feature.resizable", true);
user_pref("dom.disable_window_open_feature.scrollbars", true);
user_pref("dom.disable_window_open_feature.status", true);
user_pref("dom.disable_window_open_feature.titlebar", true);
user_pref("dom.disable_window_open_feature.toolbar", true);
user_pref("dom.disable_window_status_change", true);

This should be implemented as switchable option(!), not by default!
Flags: blocking1.8b4?
Flags: blocking-aviary1.1?
Flags: blocking1.8b4?
Flags: blocking1.8b4-
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.1-
Flags: blocking1.9a1?
Flags: blocking-aviary2.0?
Keywords: access
If the programmer wrote "resizable=no", then s/he did it deliberately.  Yes, it sometimes makes for ugliness if the window size isn't right.  But that doesn't mean that the browser should refuse to respect a feature that has been around for a long time.

To assert that we "know", better than the Web page programmer, why feature X or Y is or isn't required, is supreme arrogance on our part.  If we wanted that, we'd use Crimosoft products.

Nick: nick(dot)brown(at)coe(dot)int

I disagree.  It is nigh on impossible to make a window always the 
right pixel size regardless of the user's settings, and so it makes 
sense that we should be able to resize it if it isn't right.  If 
anybody is being arrogant, then it is the web developer by pretending 
otherwise.

I also disagree with Comment #7. This comment assumes that web page designers understand what they are doing. Generally, they don't. 

Firefox users have many needs. We now have a Firefox Accessibility Project that is attempting to address the needs of people with visual acuity problems. A routine accessibility strategy is to enlarge text. Typical unresizable unscrollable windows make no provisions for larger type. Apparently the designers are aiming for prettiness rather than readability. There is no reason that we Firefox users should put up with this.

In fact, one way of differentiating Firefox from IE would be to allow right-clicking where it is not allowed and to allow resizing and scrollbars where designers purport to disallow them. Although this is not the bug to be stumping for by default not allowing right-clicking to be disabled, I do argue for by default not allowing web designers to deprive Firefox users of data.
> If the programmer wrote "resizable=no", then s/he did it deliberately.  Yes, it
> sometimes makes for ugliness if the window size isn't right. 

Who exactly is the best person capable of determining if a window size is right or is not right? The user using that window or the web author?

> But that doesn't
> mean that the browser should refuse to respect a feature that has been around
> for a long time.
 
Opera 7 beta 1 released more than 30 months ago decided to remove all the time (to ignore all the time) resizable=no. Since then, I have not seen a single complaint about this. Today, the latest release (Opera 8.50) and beta (Opera 9.0 beta 1) still ignore resizable=no.

Most web authors do not even know that they have to explicitly declare windowFeatures that are turn on when the windowFeatures string list is not empty.  A missing "resizable=yes" becomes an implicit "resizable=no" in such cases, in the majority of cases implying secondary windows. So that is why a majority of requested popup brought up by window.open() create - unintentionally most of the time - non-resizable secondary window. So, what you say and claim "s/he did it deliberately" (suggesting that he knows what s/he's doing) is not true in a wide majority of cases: it's the opposite. Knowledge base item 211068 is a consequence of this.

> To assert that we "know", better than the Web page programmer, why feature X or
> Y is or isn't required, is supreme arrogance on our part.

My own experience of assisting in web programming newsgroups suggest exactly the opposite: a wide majority of average web authors do not know that a non-empty windowFeatures string list makes all non-declared window features turn OFF, not turn on. Even many javascript copy-N-paste sites do not explain this and do provide the user with code that will turn off resizability of secondary windows.
A wide majority of avg. web authors do not know that declaring font-size with px unit is what makes a webpage non-scalable in MSIE 6. Etc,etc,et.

>  If we wanted that,
> we'd use Crimosoft products.

Many people in several pages of channel 9 (the feedback pages on MSIE:
http://channel9.msdn.com/wiki/default.aspx/Channel9.InternetExplorerFeedback
) have requested that secondary window (requested popups) to be resizable at all times. 

This bugfile 177838 is in the same spirit of neutralizing webpage annoyances for the users so that they don't feel overwhelmed or powerless or helpless by complex UI design or by having to search long just to find 

http://www.mozilla.org/support/firefox/tips#beh_window_open_feature

which goes saying: "// Make sure all pop-up windows are resizable:
user_pref("dom.disable_window_open_feature.resizable", true);"
and then, have to search+find+read+understand how to create and edit an user.js file.

Making a browser window not resizable is most likely going against User Agent Accessibility Guidelines 1.0; it's definitely a serious usability burden. Have you tried to surf a few days/weeks with a non-resizable browser window?
Flags: blocking-aviary2? → blocking1.8.1?
Blocking+ for a pref, if not indeed just making them all resizeable.
Flags: blocking1.8.1? → blocking1.8.1+
Needs to be developed on the trunk.  Not going to block FF2 for this.
Flags: blocking1.8.1+ → blocking1.8.1-
It's not exactly a hard change to make, but better late than never.
we think this sounds good. patches?
Flags: blocking1.9a1? → blocking1.9-
Whiteboard: [wanted-1.9]
This needs some arch decisions: do we do this in the window watcher (which would effectively mean that all Gecko apps no longer get this flag), or do we do this in the window creator (so say Camino would have to make this change separately).  Along the same lines, do window.open() calls from chrome, or not from JS, also get resizable=no ignored?
Since this is not going in Fx 2.0, why not simply take the proposed defaults from my comment #5 and stick them in firefox.js on the trunk? Then we will be able to see the effects over the next six months, and decide what to do with any larger considerations.
1)  Pretty much nobody is testing the trunk as far as I can tell.
2)  Most of those prefs have nothing to do with this bug (and a few would break
    web sites right and left).
3)  Why bother?  We agree we want to do this; the only question is whether this
    should be up to the Gecko embeddor or handled completely by Gecko.  And if
    the former, what the default should be.  The answers to those questions
    determine the implementation strategy.
Personally I think all windows should always be resizable *except* when resizing a window requires extra window decoration. In particular IIRC Mac windows don't have interactive borders except for the title bar, so making those windows resizable requires you to add a resize handle in the bottom right corner of the window which can be ugly and interfere with content.

I can't think of a good reason to honour resizable=no on Windows or Linux.
As long as the status bar is always shown (which is true by default), there's plenty of room for a resize handle, even on Mac.
Chrome should retain the ability to create non-resizable windows.  Lots of windows and dialogs are not resizable, including Firefox preferences and alert().
Jesse, I view non-resizable chrome windows (as opposed to dialogs) as a bug, myself, esp. when the text in them doesn't fit (which is often enough, for me).  But I've been outvoted on this before.... ;)

The question still remains of whether this should be the case for all Gecko clients or handled in the app layer.  Given that we're talking about specific UI details (like "always have a status bar"), sounds like the latter.
(In reply to comment #20)
> Chrome should retain the ability to create non-resizable windows.  Lots of
> windows and dialogs are not resizable, including Firefox preferences and
> alert().
> 
The non-resizable Firefox pref windows is a huge bug. 

Although those of you who use micro-sized text would never know it, users who use large text can have great troubles with any fixed-size window (see my comment at #5). In my large-icon/large-text themes I have had to include scrollbars in Firefox pref windows to accommodate the large text in fixed windows. The results are ugly, and the scrollbars are often not enough.

Also, think about the fact that 24-inch iMacs come with 1920x1200 pixel displays. For users who need large text (all of us old ****), that means the text size will have to grow despite a fixed-size prefwindow.

All of this is true for popup windows, but in spades (i.e.--even more so). 

The best workaround is installing TBP and setting all popups to come up as new tabs and not new windows.

What prevents us from setting dom.disable_window_open_feature.resizable = true right now?
Re Comment 23: the settings I listed in Comment 5 come directly from my user.js file. You also can do this easily from about:config. The problem is that many users - especially many users who need large text - lack the sophistication needed to learn that such changes are possible. 
> What prevents us from setting dom.disable_window_open_feature.resizable = true
> right now?

Pushback from site authors, if anything.  It wouldn't break anything from a user perspective, for sure.
Attached patch patch — — Splinter Review 
Assignee: general → dao
Status: NEW → ASSIGNED

        Attachment #287221 -
        Flags: superreview?(bzbarsky)

        Attachment #287221 -
        Flags: review?(bzbarsky)

    
    

    
  
I'm not willing to review this patch, sorry.  This needs buy-in from jst and sicking at the very least, and perhaps even some public discussion.


        Attachment #287221 -
        Flags: superreview?(bzbarsky)

        Attachment #287221 -
        Flags: review?(bzbarsky)

    
    

    
  
Comment on attachment 287221 [details] [diff] [review]
patch

I don't think there's much to discuss -- I haven't seen an argument why this shouldn't be done, put comment 7 aside, which wasn't very convincing. This bug is also marked as [wanted-1.9].

        Attachment #287221 -
        Flags: superreview?(jst)

        Attachment #287221 -
        Flags: review?(jonas)

    
  
OS: Windows XP → All
QA Contact: desale → general
Hardware: PC → All

    
    

    
  
I would actually prefer to simply remove all support for resizable=no, for all gecko apps. This is something that is bad for users so I don't see why any other embedding app would want it. If they really do come screaming we can always add it back and disable by default for firefox only.

Dao: Do you think you could produce such a patch?

    
    

    
  
Jonas, you want to remove resizable=no support for chrome code too?

Note that this patch does change all Gecko apps, pretty much.  Changing just Firefox would involve changing firefox.js.

    
    

    
  
Chrome dialogs that are non-resizable are just as annoying when the font size differs from the designer's own settings as content dialogs are. Also, when layout.css.dpi is high enough to cause the content to be scaled, we don't also scale the window sizes. That's a separate bug of course, but it makes this one much worse as it means that all dialogs (chrome or content) are a quarter of the size needed to view their content. As such, I don't see any problem with ignoring resizable=no entirely.

    
    

    
  
The problem is that it would put resize handles on windows that just shouldn't have them, seriously breaking platform consistency...

    
    

    
  
Could you possibly mention a few examples of windows that should not have resize handles? People who have fonts enlarged do so through various methods - system fonts, minimum app fonts, etc. 

I can tell you that having large fonts in fixed windows means that I must put "overflow: auto !important;" lines in a number of places. Putting scrollbars in those windows makes them even more of a mess, and still doesn't render everything available to the user.

Lest you believe that this is a problem only for people with poor vision, consider that the various Gecko apps are mainly bitmapped (I have yet to see a window specified in em's or ex's). As screen resolutions climb upward (consider, for example, someone using his high-definition TV as a monitor), more and more normal users are going to be specifying larger fontsizes. Gecko/moz/Firefox should be able to accommodate them.

    
    

    
  
Hmm.. I guess we might want to allow chrome to use resizeable=no. I thought we used different APIs to do that usually though?

    
    

    
  
What do resize handles have to do with anything? Just because we support one OS that draws a resize handle rather than a border around the window (a border that is sometimes resizable and sometimes not) doesn't mean we have to support fixed size windows.

    
    

    
  
(In reply to comment #29)
> I would actually prefer to simply remove all support for resizable=no[...]
> 
> Dao: Do you think you could produce such a patch?

Possibly. I don't know that code at all and I'm concerned about breaking things like window decorations for chrome windows, but I'd start with doing an MXR search for CHROME_WINDOW_RESIZE...

I'm not sure if that's worthwhile, though. Depending on whether such a change would affect chrome windows, we'd have to start a whole new discussion. I would assert that application developers do restrictions like that more thoughtfully than Web developers. For instance, if there's no good reason to make the size of Firefox' preferences window fixed, we should fix that on the Firefox side.

Changing all.js would be less radical and as Boris points out, it would affect all Gecko apps. If other vendors take a different view, we don't have to do anything other than pointing to the pref.

    
    

    
  
We definitely must support non-resizable windows in chrome: UX guidelines state that most dialogs should be a fixed size (if you're lucky, specified in EM units instead of in pixels).

    
    

    
  
(In reply to comment #33)
> Could you possibly mention a few examples of windows that should not have
> resize handles?

alert/prompt/confirm dialogs.  Anything that's a sheet on OSX.  Various modal non-content alerts.

> (I have yet to see a window specified in em's or ex's)

Uh... Did you look at all?  The preferences window is sized in em and has been for a very long time.  Any window that's not and that's not resizable is just a bug; feel free to file it.

In any case, I think you missed the point.  There is a difference between "the ability to open unresizable windows should not be available" and "the ability to open unresizable windows should be used sparingly".  I agree with the latter, but not the former.

(In reply to comment #34)
> I thought we used different APIs to do that usually though?

http://mxr.mozilla.org/firefox/search?string=resizable%3Dno

(In reply to comment #35)
> What do resize handles have to do with anything? Just because we support one
> OS that draws a resize handle rather than a border around the window 

You mean like Mac and (often) Linux?  That's sort of "more than one OS".

> doesn't mean we have to support fixed size windows.

If we want to support application development, we should support fixed size windows.  If an app misuses them, please file bugs.

I fully agree with comment 36.

    
    

    
  
One question is, should we add UI to turn this back on? I think we might actually.

    
    

    
  
Why would a user want to turn it back on?

    
    

    
  
Hmm.. I was originally thinking for the same reason that they'd want to turn on anything else in the "Advanced JavaScript settings" dialog. But those things can actually break websites, whereas I can't think of a way that this would. So I think you're right.

    
    

    
  
Comment on attachment 287221 [details] [diff] [review]
patch

sr=jst, I'm all for doing this.

        Attachment #287221 -
        Flags: superreview?(jst) → superreview+

    
  

        Attachment #287221 -
        Flags: approval1.9?

    
  
Depends on: 402866

    
  

        Attachment #287221 -
        Flags: approval1.9? → approval1.9+

    
  
Keywords: checkin-needed

    
    

    
  
Checking in modules/libpref/src/init/all.js;
/cvsroot/mozilla/modules/libpref/src/init/all.js,v  <--  all.js
new revision: 3.700; previous revision: 3.699
done
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9 M10

    
  
Flags: wanted1.9+
Whiteboard: [wanted-1.9]

    
    

    
  
This is a very bad move IMO. A lot of developers rely on being able to fix the size of popup windows for a range of things including games and fixed-size web applications. The browser should not dictate what functionality a user defined window should or should not have. The obvious exception to this are features such as full-screen mode which present obvious security issues.

If an end-user really wants to be able to resize every single window then there should be a Firefox option that ignores the "resizable" feature, but that option should not be enabled by default.

Even though I am pro-XHTML/CSS I am also open minded enough to know that the web isn't just about XHTML/CSS development, and not every web page needs to be accessible to everyone and their dog. How a website is developed is the choice of the website developer(s), not the browser developers.

    
    

    
  
> This is a very bad move IMO. A lot of developers rely on being able to fix the
> size of popup windows for a range of things including games and fixed-size web
> applications.

I don't understand these use cases. What will happen if the user resizes a window with a game inside?

> The browser should not dictate what functionality a user defined
> window should or should not have.

Exactly, so we leave it up to the user to change the size if he/she wants to.

> If an end-user really wants to be able to resize every single window then there
> should be a Firefox option that ignores the "resizable" feature, but that
> option should not be enabled by default.

I would rather say; if a user really doesn't want to be able to resize his/her windows it should be possible to enable an option like "let websites open windows that can't be resized". I just have a hard time thinking that very many users would be interested in turning on such a preference. None-the-less we do still have such a pref, just without a UI.

> Even though I am pro-XHTML/CSS I am also open minded enough to know that the
> web isn't just about XHTML/CSS development, and not every web page needs to be
> accessible to everyone and their dog. How a website is developed is the choice
> of the website developer(s), not the browser developers.

Our first priority is the users. There are a lot of things that web developers want to do that can be annoying and/or insecure to the user. Popups fall into the same category.

Web developers are of course still very important to us, which is why we're working very hard to support standards and have good development tools. However I don't see how enabling unresizeable windows would let developers create sites that are better for users.

    
    

    
  
> What will happen if the user resizes a
> window with a game inside?
 
I've been playing Yahoo games and have resized and maximized all my secondary windows and never had a problem. In fact, I had less problem after resizing, maximizing the window.

> if a user really doesn't want to be able to resize his/her
> windows it should be possible to enable an option like "let websites open
> windows that can't be resized". I just have a hard time thinking that very many
> users would be interested in turning on such a preference. None-the-less we do
> still have such a pref, just without a UI.

This option already exists and, in fact, always existed. It is in the user's mind: it is all up to him/her to resize the window... if that is what he/she wants. The browser here, with bug 177838 fixed, makes no attempt to stop the user's will.

    
    

    
  
(In reply to comment #46)
> Web developers are of course still very important to us, which is why we're
> working very hard to support standards and have good development tools. However
> I don't see how enabling unresizeable windows would let developers create sites
> that are better for users.

In some cases, web developers can provide unique and enjoyable content for user based on modest revenue they generate from banner advertising.  If I have a window that I want to open that has a banner ad on the right side next to some interesting content, I would like the window to not be resizable so that my ads can't be hidden in the unviewable area by a user who resizes.  If the user doesn't like the ads or the non-resizable window, they don't have to view any of the content by closing the window.  They're happy and so am I since I won't generate revenue from them anyway.  If they really want to view my content, they can also view the ads that pay for it.

    
    

    
  
The user who resizes the window to hide the ad has already had the impression, and opted out.  There's plenty of ways to get rid of ads (Adblock, blocking ad servers by hostname on an OS level, etc) so resizing windows isn't some magic bullet that's unique and game changing.  This is no different from fast-forwarding through commercials on a VCR or a Tivo.  But I'm sure you'd never deprive networks of their hard-earned ad impressions like that... :D
Status: RESOLVED → VERIFIED

    
    

    
  
(In reply to comment #48)
> (In reply to comment #46)
> > Web developers are of course still very important to us, which is why we're
> > working very hard to support standards and have good development tools. However
> > I don't see how enabling unresizeable windows would let developers create sites
> > that are better for users.
> 
> In some cases, web developers can provide unique and enjoyable content for user
> based on modest revenue they generate from banner advertising.  If I have a
> window that I want to open that has a banner ad on the right side next to some
> interesting content, I would like the window to not be resizable so that my ads
> can't be hidden in the unviewable area by a user who resizes.  If the user
> doesn't like the ads or the non-resizable window, they don't have to view any
> of the content by closing the window.  They're happy and so am I since I won't
> generate revenue from them anyway.  If they really want to view my content,
> they can also view the ads that pay for it.

Yes. Agree. I have pages like windows application, don't let user to resize it (it is fine in IE, why FF remove it? who got this idea???)

    
    

    
  
of course, you guys who love small print, and create web pages will never understand . . . until you get older. I'm 60, and I use the larger OS font size, and I resize text all the time. 

And website developer usually make their popup windows of fixed size, and when your text is large the window is too small for the content. With no scrollbars and no resizing, the large text user is SOL.

This is an Accessibility issue. In theory we could file ADA actions for all of these websites. In practice, I use a user.js file. Most users my age don't know how to do that.

Giving the choice to website designers is wrong.

    
    

    
  
@Gérard Talbot 

I don't usually waste my time adding comments to things like this (I actually have better things to do) but this feature (the resizing of pop-ups) affects me as of this morning.  It's not a huge deal I can live without it and there are ways round it but never-the-less something got my goat.  First off I hate this “the customer’s always right self-righteous attitude” – where do they think we are, McDonalds?

Gérard Talbot seems to suggest that as a web developer I am an idiot and that I don't know what I am trying to achieve on my sites and furthermore I don’t understand how my design’s will affect the end user.  This is nonsense!  As developers we are the knowledgeable responsible adults of the internet (who understand basic things like screen resolutions and multi-platform applications) and when dealing with average Joe (the client) sometimes we need to "help" them by restricted certain aspects of their user experience just in the same way we make our layouts easy to navigate (like spoon feeding a baby)

So quite clearly the opposite is true as to the reasoning behind the non-implementation of this feature.

It should be us (the developer) who makes the decision as to weather a resize should be available - what do they think is going to happen? - we're going to make all our sites 100px*100px so they become unusable? Certainly not!  Furthermore I would suggest that a developer that makes a site that is shocking pink and has it's navigation three miles down at the bottom of the page would also be creating an unnecessarily bad user experience... so what's next? Pink to be removed from browsers. No hyperlinks below a certain points of the page.  Obviously that is silly but the point is, WE should make these decisions NOT the user. If people don't like what they see go to a different page (I lose out).

Stop treating us like kids!

ps an example of not wanting to resize a browser could be as simple as have a fixed-sized flash app (e.g. jukebox) that cannot be viewed at any other size.  Why should I confuse my user by giving them an unnecessary function that will in effect tarnish their experience...

ANSWER THAT BUDDY!

Yours,
Disgruntled Developer

    
    

    
  
(In reply to comment #52)
> Furthermore I would suggest that a developer that makes a site that is shocking
> pink and has it's navigation three miles down at the bottom of the page would
> also be creating an unnecessarily bad user experience... so what's next? Pink
> to be removed from browsers. No hyperlinks below a certain points of the page.

Not quite. But we do allow users to disable stylesheets or override suboptimal aspects of them, as well as we allow them to block certain content. You're not going to have full control over this, sorry.

    
    

    
  
> we're going to make all our sites 100px*100px so they become unusable?
> Certainly not! 

Unfortunately... yes, you are.  Not you personally, perhaps, but web developers in general do this all the time.  Nothing as stupid as 100x100, but I've seen plenty of 300x300 windows that cut off the text the web developer wants me to read because he assumed that everyone would be happy with the 8px font he specified for that text...  Luckily, I can resize these windows (and yes, a number of them do have resizable=no set).

    
    

    
  
@Boris Zbarsky (:bz)
I don't know what "web developers" you are referring to but what you have described is quite obviously an oversight by someone who I wouldn’t class as competent... Stating “web developers in general” is a ludicrous thing to say as it’s simply not true. NO professional developer would be that dumb!  What you're actually suggesting is that we penalize the many for the few.  Anyway why not let bad developers make their mistakes it’s a good way to learn and is good business for all of us “competent” guys!

Best,
DD

    
    

    
  
Anton, most people who create "professional" websites do in fact seem to be incompetent.  This has been the case with every single bank web site I've seen, for example; they all break if you change the fonts a tiny bit.  I'm glad you don't make that sort of mistake, and that none of the people you know professionally do either, but since it's so commonly made by others we have to give our users a way to deal with it.

Also note that there are generally no consequences to the creator of such a site, since user complaints to the bank or whatever just routinely get ignored, and certainly aren't passed on to someone who contracted to create the site a year ago and isn't around anymore.  So people are not in fact learning from their mistakes...  It's unfortunate, but that's the world we have to deal with.

    
    

    
  
Boris, first off why are you changing the font? Are you talking about "zooming in"? If so this is an inherent problem of browsers/OS'/graphics cards... NOT developers!  It is becoming a huge problem as we all rush to stick the internet on our 50" flat screen TV's and can't see s*** at 1080p.  Maybe you guys should implement a better system for scaling sites (that works across the board).

As far as people not learning I think they do learn but they just take the money and run... chances are they won't make the same mistake on the next project... It is the clients responsibility to sign-off when they are happy.  I wouldn't want a phone call from a client a year later saying "Mrs. Blah has bought a new TV and now your site can't be viewed properly." - It's not my problem!

FYI I've just logged in to HSBC internet banking at full zoom and it worked perfectly so my original few for the many point still stands.

    
    

    
  
(In reply to comment #53)
> (In reply to comment #52)
> > Furthermore I would suggest that a developer that makes a site that is shocking
> > pink and has it's navigation three miles down at the bottom of the page would
> > also be creating an unnecessarily bad user experience... so what's next? Pink
> > to be removed from browsers. No hyperlinks below a certain points of the page.
> 
> Not quite. But we do allow users to disable stylesheets or override suboptimal
> aspects of them, as well as we allow them to block certain content. You're not
> going to have full control over this, sorry.

As has already been mentioned (by Norbert): no developer wants to deprive the end user of personalising their viewing experience but (as in both cases) they should NOT be set as default / removed completely... and I don't know any common user who alters CSS properties across the board... that is ridiculous no wonder they are having problems viewing sites correctly... anyway it is quite clear that you are on the side of your customers and not those who put the content there in the first place as our problems are not your concern we just have to keep finding more "workarounds"!

    
    

    
  
> Boris, first off why are you changing the font?Because at my resolution and monitor size I can't read 8px text.  So I have a minimal font size set that I _can_ read.  My problem is the opposite of the one you seem to be thinking about; my monitor is higher resolution than the one the web site developer is using, so text he thinks is "just fine" is way too small to be readable.As for HSBC....  https://www.us.hsbc.com/1/2/3/personal/online-services/personal-internet-banking/log-on has cut-off text (the beginning of "Personal" after "Other services" with my minimal font size setting of 13px.  If you log in and click "Bank to Bank Transfers", the window it opens is way too small to fit the content at that font size (and isn't big enough to fit the content at the default font size either, fwiw).  There are various other issues with the site that I don't think it's worth my time to dig up, but HSBC was in fact included in my "every single bank web site" claim above.Seriously, most people creating web sites create web sites that don't deal with fonts other than the exact ones they had well at all.  I suggest setting a 13px minimum font size (or 16px if you're feeling adventurous and happen to have a 200dpi monitor) and browsing the web for a few days to get an idea of how things look.

    
    

    
  
To coin a FF phrase “How embarrassing” It seems that your comment has not adhered to your CSS... so the question is... Is it firefox to blame OR the incompetent people who made the website? The mind boggles...

    
    

    
  
ps fear not I have copied your comment into notepad which seems to manage word-wrap successfully...;0

    
    

    
  
Ah, the line-wrapping issue is a known bug in current Firefox nightlies.  Never fear, it will be fixed before release.  ;)  I'm glad you managed to read the comment nevertheless.

    
    

    
  
(In reply to comment #59)
> Boris Zbarsky (:bz)
> > Boris, first off why are you changing the font?Because at my resolution and >monitor size I can't read 8px text.  So I have a minimal font size set that I >_can_ read.  My problem is the opposite of the one you seem to be thinking >about; my monitor is higher resolution than the one the web site developer is >using, so text he thinks is "just fine" is way too small to be readable.

ERM...

this is what a said originally:

"Are you talking about "zooming in"? If so this is an inherent problem of browsers/OS'/graphics cards... NOT
developers!  It is becoming a huge problem as we all rush to stick the internet
on our 50" flat screen TV's and can't see s*** at 1080p.  Maybe you guys should
implement a better system for scaling sites (that works across the board)."

Which if read is exactly what you're describing!

>Boris Zbarsky (:bz)
> As for HSBC....  https://www.us.hsbc.com/1/2/3/personal/online-services  >/personal-internet-banking/log-on has cut-off text (the beginning of >"Personal" after "Other services" with my minimal font size setting of 13px.  >If you log in and click "Bank to Bank Transfers", the window it opens is way >too small to fit the content at that font size (and isn't big enough to fit >the content at the default font size either, fwiw).  There are various other >issues with the site that I don't think it's worth my time to dig up, but HSBC >was in fact included in my "every single bank web site" claim above.

I'm sorry I didn't realise you where talking about "every single US bank website" have you tried online banking abroad? I recommend it! 

>Boris Zbarsky (:bz)
>Seriously, most people creating web sites create web sites that don't deal >with fonts other than the exact ones they had well at all.  I suggest setting >a 13px minimum font size (or 16px if you're feeling adventurous and happen to >have a 200dpi monitor) and browsing the web for a few days to get an idea of >how things look.


16px looks ugly on 1024*768 which is STILL the most common screen res so what you're suggesting is that I make websites display well for the elite and forget about the majority of more humble browsers who don't use a 200dpi monitor to view websites.  

That doesn't sound very fair does it?...

    
    

    
  
(In reply to comment #59)
> Boris Zbarsky (:bz)
> > Boris, first off why are you changing the font?Because at my resolution and >monitor size I can't read 8px text.  So I have a minimal font size set that I >_can_ read.  My problem is the opposite of the one you seem to be thinking >about; my monitor is higher resolution than the one the web site developer is >using, so text he thinks is "just fine" is way too small to be readable.

ERM...

this is what a said originally:

"Are you talking about "zooming in"? If so this is an inherent problem of browsers/OS'/graphics cards... NOT
developers!  It is becoming a huge problem as we all rush to stick the internet
on our 50" flat screen TV's and can't see s*** at 1080p.  Maybe you guys should
implement a better system for scaling sites (that works across the board)."

Which if read is exactly what you're describing!

>Boris Zbarsky (:bz)
> As for HSBC....  https://www.us.hsbc.com/1/2/3/personal/online-services  >/personal-internet-banking/log-on has cut-off text (the beginning of >"Personal" after "Other services" with my minimal font size setting of 13px.  >If you log in and click "Bank to Bank Transfers", the window it opens is way >too small to fit the content at that font size (and isn't big enough to fit >the content at the default font size either, fwiw).  There are various other >issues with the site that I don't think it's worth my time to dig up, but HSBC >was in fact included in my "every single bank web site" claim above.

I'm sorry I didn't realise you where talking about "every single US bank website" have you tried online banking abroad? I recommend it! 

>Boris Zbarsky (:bz)
>Seriously, most people creating web sites create web sites that don't deal >with fonts other than the exact ones they had well at all.  I suggest setting >a 13px minimum font size (or 16px if you're feeling adventurous and happen to >have a 200dpi monitor) and browsing the web for a few days to get an idea of >how things look.


16px looks ugly on 1024*768 which is STILL the most common screen res so what you're suggesting is that I make websites display well for the elite and forget about the majority of more humble browsers who don't use a 200dpi monitor to view websites.  

That doesn't sound very fair does it?...

    
    

    
  
I'm not suggesting you do anything either than either design sites that work well at a variety of user settings (including different colors or font sizes) or accept that users will override parts of your design which break due to you not bothering to think about how your design will work if user settings are changed.  

In practice, most people don't do the former, so they just need to accept the latter.  Not much more to say here.

    
    

    
  
I take offence to you making your references to me directly as I have already mentioned any competent developer DOES take these things in to consideration at stage 1 and DOES NOT want to be treated like an idiot by browser folk... 

From now on I'll build all my sites with a minimum of 16px font size and tell the clients that the reason most people can't see it is that Boris from Firefox wants to be able to see on his 200dpi monitor...

    
    

    
  
(In reply to comment #57)
> Boris, first off why are you changing the font?  Are you talking 
> about "zooming in"?  If so this is an inherent problem of 
> browsers/OS'/graphics cards...  NOT developers!  It is becoming a 
> huge problem as we all rush to stick the internet on our 50" flat 
> screen TV's and can't see s*** at 1080p.  Maybe you guys should 
> implement a better system for scaling sites (that works across the 
> board).

No system can scale every site well, regardless of how well or ill put together it is.

If a given site doesn't work properly when the text is zoomed, the window is narrowed, etc. then that is the fault whoever developed the site.

Of course, it's an unfortunate fact that people do things to websites that compromise their accessibility in various ways.  That's why we have enhancement requests like this, and bug 86194 generally.

    
    

    
  
(In reply to comment #67)
> (In reply to comment #57)
> > Boris, first off why are you changing the font?  Are you talking 
> > about "zooming in"?  If so this is an inherent problem of 
> > browsers/OS'/graphics cards...  NOT developers!  It is becoming a 
> > huge problem as we all rush to stick the internet on our 50" flat 
> > screen TV's and can't see s*** at 1080p.  Maybe you guys should 
> > implement a better system for scaling sites (that works across the 
> > board).
> 
> No system can scale every site well, regardless of how well or ill put together
> it is.
> 
> If a given site doesn't work properly when the text is zoomed, the window is
> narrowed, etc. then that is the fault whoever developed the site.
> 
> Of course, it's an unfortunate fact that people do things to websites that
> compromise their accessibility in various ways.  That's why we have enhancement
> requests like this, and bug 86194 generally.

I'm not sure what you mean by system? are you referring to a computer including  OS/browser/FX card? If so scaling is still in its infancy across the board as we deal with higher resolutions being introduced.  Most OS' allow you to use big icons for this reason and so it is not too far a stretch to accept that browsers / GFX manufacturers will start making default scaling based on the output device.  It is silly that web browsers don't automatically scale content based on the resolution of the monitor so that people (like boris) don't have to increase the zoom factor which conflicts with HTML as a whole and is certainly NOT the developers fault. Here's a simple equation: WEBSITE WORKS FINE FOR 1024, 1280 -> CONSUMERS BUY HIGHER RES -> GREATER SCREEN RES RANGE ACROSS ALL CLIENTS = SOFTWARE/HARDWARE DESIGNERS SCALE OUTPUT ACCORDINLY.  The ONLY people that have access to actual screen size information are those who have executable programs installed on the user’s computer...

To summarise it is ridiculous to expect me (or any other developer) to cater for screen resolutions with such a vast range when you could quite easily scale at the user end!

    
    

    
  
(In reply to comment #68)
> I'm not sure what you mean by system?

I suppose "method of scaling", which I thought was more or less what you meant.

> Here's a simple equation: WEBSITE WORKS FINE FOR 1024, 1280 -> 
> CONSUMERS BUY HIGHER RES -> GREATER SCREEN RES RANGE ACROSS ALL 
> CLIENTS = SOFTWARE/HARDWARE DESIGNERS SCALE OUTPUT ACCORDINLY.

If you want Flash, you know where to find it.  HTML pages don't have a concept of resolution.  They are just a combination of text and structural elements - logical structure, not visual structure.

And this is all for good reasons.  The site developer cannot know what kind of system (OS, browser, input mechanism, screen size/type, etc.)  the end user has, nor the end user's physical and sensory ability, and so HTML is designed as a logical markup language, not a means of specifying how a page looks.

And if we started scaling sites to the window/screen size, we'd need to redefine all CSS units as percentages of this size.  This behaviour would also conflict with user expectations - people generally increase the window size in order to see more.

> The ONLY people that have access to actual screen size information 
> are those who have executable programs installed on the user’s 
> computer...
> 
> To summarise it is ridiculous to expect me (or any other developer) 
> to cater for screen resolutions with such a vast range when you 
> could quite easily scale at the user end!

That's why good developers don't in the first place create layouts that break if the end user changes the window size or font settings.

    
    

    
  
Anton, your suggestions regarding zooming are already essentially implemented within Safari on the iPhone.  You'll see if you use that (or a netbook) that smaller resolutions are actually quite common and also a realistic problem.  Safari on the iPhone indeed institutes a minimum font size, for the very same reason Boris suggests.

And trust me, while sites have problems with the iPhone's default behavior here, people very much prefer it.  The alternatives are all worse.

If you can come up with a more perfect zooming scenario, which helps users across the board (even if they are partially blind, and yes, I care about those users even if they are less than 5% of my users) then I would love to hear it.

But as the situation stands now, with the video cards that are in computers now, the websites that actually exist now, the operating systems that people use now, these are problems AFAIK.  Firefox has to do its best to allow users, even in smaller groups that web developers don't care about (using smaller or higher resolutions, partially blind, color blind, whatever) to use the web browser properly.

I'm a professional web developer (or at least think I am one), done sites for Adobe, Fox, and other large companies, and I care about all these things.  I manage other web developers, and I'm constantly beating these ideals into them whenever I can.  I know from personal experience that Boris is right, even if I wish it weren't so.

FWIW, I'm glad this bug was fixed.  I routinely run into problems with fixed size pop ups myself (even though I use default settings), and frankly think that in retrospect, the option of disabling it was a mistake from the beginning.  Even when I use pop ups, which I rarely do, I simply design them so they work properly when resized.

Some may even want the Flash resized.  I am unclear as to why this is undesirable; it seems to be a functional improvement that doubtless helps you comply with various regulations and standards about disabled and impaired persons.

-[Unknown]

    
    

    
  
As the builder of "large" and even "jumbo" themes, object size - especially text - has long been something I harass others about. I have personally had flex overrides on all my windows for years. When I have used the browsers of others I have continued to be amazed at how intolerant most websites are regarding larger text. It seems that even the most professional website designers are all youngsters. I suppose we must wait until you all get old enough to "get" the problem.

And then there are the people who design websites as part of their other duties. No luck with the sites they slap together.

    
    

    
  
Even this does not work in Firefox 3.6. Can someone help to find the javascript code to disable pop-up window resizable property? I tried the below options which does not work in Firefox 3.6. Help me please.

1. var WindowReference = window.open(strURL, strWindowName,
"width=100,height=100,resizable=no"); 
This functionality does not work in Firefox 3.6

2. Even Firefox 3.6 prevents us from setting (using the attached patch): 
dom.disable_window_open_feature.resizable = true 
This does not work in Firefox 3.6

3. "%APPDATA%\Mozilla\"
In prefs.js or user.js if we set 
pref("dom.disable_window_open_feature.resizable", true);

- This also does not work in Firefox 3.6

4. <SCRIPT LANGUAGE="javascript">
<!--
width=700;
height=180;
window.resizeTo(width,height);
//-->
</SCRIPT>

The problem is that it works in IE but does not work in firefox 3.6.

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: