statusbar on new window in FF

[Andrew Poulos]

If I manage to call the following bit of javascript in IE and MZ

w = window.open("", "s", 'status=no,resizable=no,width=450,height=450');

I get a window that is not resizable and without a statusbar. Yet FF
gives me both a statusbar and the window is resizable! Does this mean
that FF does not support these "features" or is there a different way to
code them for FF?


Andrew Poulos

 

[Randy Webb]

If I manage to call the following bit of javascript in IE and MZ

w = window.open("", "s", 'status=no,resizable=no,width=450,height=450');

I get a window that is not resizable and without a statusbar. Yet FF
gives me both a statusbar and the window is resizable! Does this mean
that FF does not support these "features" or is there a different way to
code them for FF?

It means that Firefox does not allow you to remove that functionality of
the browser, not vice versa.

But, you should see what that code above produces in my Mozilla, with
the toolbar that I have. Its obnoxiously rude.

 

[Richard]

If I manage to call the following bit of javascript in IE and MZ

w = window.open("", "s",
'status=no,resizable=no,width=450,height=450');

I get a window that is not resizable and without a statusbar. Yet FF
gives me both a statusbar and the window is resizable! Does this mean
that FF does not support these "features" or is there a different way
to
code them for FF?

Perhaps a syntax problem?
If a syntax is wrong, firefox simply ignores it.
you might want to try something like 'status=no' ; 'resiazeable=no' ;

 

[Andrew Poulos]

It means that Firefox does not allow you to remove that functionality of
the browser, not vice versa.

I'm glad I'm not one of those overly arty types who spend weeks and
weeks hand-crafting a design (because that's what they and their users
want/need/expect/pay for) only to have it "spoilt" it by the inadvertent
resizing of the page (causing scrollbars to appear...)

Anyhow if preventing a developer from removing this functionality *is* a
good thing why is it that MZ 1.7.5 operates otherwise?

But, you should see what that code above produces in my Mozilla, with
the toolbar that I have. Its obnoxiously rude.

Hmm, I understand what you mean. The example code was for illustrative
purposes and is not "real" code. It's the sample I'm using for testing.

Interestingly enough if I turn the statusbar off using the menu item
provided, then:
- new popup windows also do not have a statusbar
- the resizable=no option is now functional

So if I want to resize a popup I should, close the popup, go to the
parent page, turn the statusbar on, re-launch the popup, and then resize
the popup... bizarre.


Andrew Poulos

 

[Randy Webb]

I'm glad I'm not one of those overly arty types who spend weeks and
weeks hand-crafting a design (because that's what they and their users
want/need/expect/pay for) only to have it "spoilt" it by the inadvertent
resizing of the page (causing scrollbars to appear...)

That comes about from the mis-conception that the web author controls
the browser when in fact it's the user who controls it.

Anyhow if preventing a developer from removing this functionality *is* a
good thing why is it that MZ 1.7.5 operates otherwise?

That I can't answer. I use Moz 1.7.5 more than FF though.

Hmm, I understand what you mean. The example code was for illustrative
purposes and is not "real" code. It's the sample I'm using for testing.

The toolbar I have is the Preferences bar that can not be removed.
Sizing the window narrower than my bar makes it inaccessible. Taking
away my Prefs Bar causes me to click the X and move on.

Interestingly enough if I turn the statusbar off using the menu item
provided, then:
- new popup windows also do not have a statusbar

That makes sense since you are telling the browser "I don't want a
statusbar"

- the resizable=no option is now functional

Functional or non-Functional? Your next statement implies that it makes
it non-Functional as to the ability to disable resizing.

So if I want to resize a popup I should, close the popup, go to the
parent page, turn the statusbar on, re-launch the popup, and then resize
the popup... bizarre.

<noted>

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq
Answer:It destroys the order of the conversation
Question: Why?
Answer: Top-Posting.
Question: Whats the most annoying thing on Usenet?

 

[Randy Webb]

Perhaps a syntax problem?

Did you test it? That would have removed the doubt.

If a syntax is wrong, firefox simply ignores it.

Bullshit.

 

[RobG]

If I manage to call the following bit of javascript in IE and MZ

w = window.open("", "s", 'status=no,resizable=no,width=450,height=450');

I get a window that is not resizable and without a statusbar. Yet FF
gives me both a statusbar and the window is resizable! Does this mean
that FF does not support these "features" or is there a different way to
code them for FF?

No and No. Did you look in help?

In Firefox, go to:

Tools --> Options... -> Enable JavaScript --> Advanced...

You will get a dialog that allows *the user* to decide whether
JavaScript can:

- Move or resize existing windows
- Raise or lower windows
- Disable or replace context menus
- Hide the status bar
- Change status bar text
- Change images

Learn to use the application before trying to program it.

 

[Zifud]

Randy Webb wrote: [...]
I'm glad I'm not one of those overly arty types who spend weeks and
weeks hand-crafting a design (because that's what they and their users
want/need/expect/pay for) only to have it "spoilt" it by the inadvertent
resizing of the page (causing scrollbars to appear...)

So all your windows are what, 600x400? Or do all your users have
exclusively one size of window? Which infers they *always* have a
monitor large enough to display your page "unspoiled" by UI features
designed to allow them to see what would otherwise be invisible.

Or would you rather be able to position window controls off the screen
so users can't reach the edges to resize the window or the controls to
close the window?

Anyhow if preventing a developer from removing this functionality *is* a
good thing why is it that MZ 1.7.5 operates otherwise?

It doesn't - it's actually exactly the same as Firefox. You just
haven't bothered to learn where the settings are to change the
behaviour of either product.

[...]
Interestingly enough if I turn the statusbar off using the menu item
provided, then:
- new popup windows also do not have a statusbar
- the resizable=no option is now functional

So if I want to resize a popup I should, close the popup, go to the
parent page, turn the statusbar on, re-launch the popup, and then resize
the popup... bizarre.

Yes ... and no. The user can stop a script from changing the status
bar text *and*, independently, stop a script from hiding the status bar
itself.

Learn about the application first, then you can comment intelligently.

 

[Andrew Poulos]

Randy Webb wrote:
[...]

I'm glad I'm not one of those overly arty types who spend weeks and
weeks hand-crafting a design (because that's what they and their users
want/need/expect/pay for) only to have it "spoilt" it by the
inadvertent resizing of the page (causing scrollbars to appear...)

So all your windows are what, 600x400? Or do all your users have
exclusively one size of window? Which infers they *always* have a
monitor large enough to display your page "unspoiled" by UI features
designed to allow them to see what would otherwise be invisible.

Or would you rather be able to position window controls off the screen
so users can't reach the edges to resize the window or the controls to
close the window?

Thank you for the usability lesson. Wouldn't it have been more
appropriate for you to say something like "the default settings of FF
prevent code access to the visibility of the statusbar and, at any rate,
I believe that it is generally bad to control a user's browser
experience in this way"? Allowing for the condition, as improbable as it
might seem to you, where everyone concerned wants (in fact, demands)
just this lack of user control.

It doesn't - it's actually exactly the same as Firefox. You just
haven't bothered to learn where the settings are to change the
behaviour of either product.

Well, I have not changed the default settings of either MZ nor FF so for
me they do behave differently. It took me about 15 minutes to find the
setting in FF. Do you think many non-developer users even know these
settings exist?

[...]

Interestingly enough if I turn the statusbar off using the menu item
provided, then:
- new popup windows also do not have a statusbar
- the resizable=no option is now functional

So if I want to resize a popup I should, close the popup, go to the
parent page, turn the statusbar on, re-launch the popup, and then
resize the popup... bizarre.

Yes ... and no. The user can stop a script from changing the status
bar text *and*, independently, stop a script from hiding the status bar
itself.

Status bar text??? Let me rephrase the question, so what does the
visibility of the statusbar in FF have to do with whether or not the
user can resize the window?

Learn about the application first, then you can comment intelligently.

I'm trying to learn about the application, that's why I'm asking
questions. Though I did not note anywhere in the press release that FF
prevented certain scripts from running:
<url:http://www.mozilla.org/products/firefox> but it does say that it's
a "Developers Best Friend".

Andrew Poulos

 

[Zifud]

Andrew Poulos wrote:
[...]

experience in this way"? Allowing for the condition, as improbable as it
might seem to you, where everyone concerned wants (in fact, demands)
just this lack of user control.

Your original post was already answered. Your follow-up question was:

Your assumption regarding Mozilla is incorrect.

I presume you are developing an intranet application for a select set
of users who have asked that their ability to resize and reposition
windows be removed.

[...]

Well, I have not changed the default settings of either MZ nor FF so for
me they do behave differently. It took me about 15 minutes to find the
setting in FF. Do you think many non-developer users even know these
settings exist?

Actually, yes. You would be amazed at how many dedicated IE users I
converted to Firefox simply because of tabs. And they very quickly
learned many of Firefox's features such as controlling pop-ups and what
scripts could do to their UI.

But the point it moot. What *is* irrelevant is that
you have discovered that you can't depend on the browser doing what you
think it is doing - the same browser will act differently depending on
the users' settings.

And if you want help on Mozilla or Firefox, try one of the links on
their support page - just one click from the home page:

* Official Online Documentation
* Frequently Asked Questions
* Intro to Firefox (Nidelven IT)
* Knowledge Base (MozillaZine)
* Community Support Forums
* Third-Party Support

<URL:http://www.mozilla.org/support/>

[...]

Status bar text??? Let me rephrase the question, so what does the
visibility of the statusbar in FF have to do with whether or not the
user can resize the window?

You brought it up, presumably because you felt it important to your use
case. I think the general gist is that you can't reliably control the
UI features of a browser unless you are the user.

Web development turns normal application development on its head. You
are delivering content, not an application. You are giving the user
information, not functionality.

Intranet development is more like traditional application development,
but constrained by underlying intentions of the Internet and World Wide
Web, which were both developed first and foremost to aid the free
exchange of information. The basis of the Internet is anarchy, where
the only rule is that there are no rules.

You should not hope to control a users' browser any more than you
can control their screen size or keyboard layout. And if you can
control their screen size and keyboard layout, you can probably control
their choice of browser and how it is set up.

 

[DU]

Randy Webb wrote:

[...]

I'm glad I'm not one of those overly arty types who spend weeks and
weeks hand-crafting a design (because that's what they and their
users want/need/expect/pay for) only to have it "spoilt" it by the
inadvertent resizing of the page (causing scrollbars to appear...)

Scrollbars are not a defect, an illness to a window; quite on the
contrary. You should enable them if content overflows window dimensions;
you should not disable them when creating a secondary (script-initiated)
window.

Thank you for the usability lesson.

Sorry there but the major browser manufacturers are no longer waiting
and expecting amateur web authors to understand (basic usability lesson)
that removing the statusbar and disabling window resizability is a very
bad thing. XP Pro SP2 now forces statusbar on all script-initiated
windows, period. Opera 7.x gives entire veto power to its users to force
status bar presence. Firefox 1.0 default setting is to force statusbar,
notwithstanding giving too entire veto power to its users regarding
window toolbars presence and window funtionalities (scrollbars if
needed, resizability, modality, dependence, system command icons, etc.).

Wouldn't it have been more

appropriate for you to say something like "the default settings of FF
prevent code access to the visibility of the statusbar and, at any rate,
I believe that it is generally bad to control a user's browser
experience in this way"?

[snipped]

People in this newsgroup have been saying that for years and browser
manufacturers have listened, have understood and have echoed loud and
clear their demands. Many security hacks and exploits first start with
removing the statusbar.

Let me rephrase the question, so what does the
visibility of the statusbar in FF have to do with whether or not the
user can resize the window?

There is a window resizing grippy at the right end of the
Firefox/Mozilal statusbar.

I'm trying to learn about the application, that's why I'm asking
questions.

Mozilla and Firefox users can force all windows to be easily resizable
by setting
dom.disable_window_open_feature.resizable
to true in about:config or in their user.js file.

Though I did not note anywhere in the press release that FF

prevented certain scripts from running:
<url:http://www.mozilla.org/products/firefox> but it does say that it's
a "Developers Best Friend".

Andrew Poulos

in MSIE 6 for XP SP2: "For windows opened using window.open():
Expect the status bar to be present, and code for it. The status bar
will be on by default and is 20-25 pixels in height. (...)" taken from
Fine-Tune Your Web Site for Windows XP Service Pack 2, Browser Window
Restrictions in XP SP2
http://msdn.microsoft.com/security/...ary/en-us/dnwxp/html/xpsp2web.asp#xpsp_topic5

"(...) windows that are created using the window.open() method can be
called by scripts and used to spoof a user interface or desktop or to
hide malicious information or activity by sizing the window so that the
status bar is not visible.
Internet Explorer windows provide visible security information to the
user to help them ascertain the source of the Web page and the security
of the communication with that page. When these elements are not in
view, the user might think they are on a more trusted page or
interacting with a system process when they are actually interacting
with a malicious host. (...)
Script-initiated windows will be displayed fully, with the Internet
Explorer title bar and status bar. (...)
Script management of Internet Explorer status bar
Detailed description
Internet Explorer has been modified to not turn off the status bar for
any windows. The status bar is always visible for all Internet Explorer
windows. (...) Without this change, windows that are created using the
window.open() method can be called by scripts and spoof a user interface
or desktop or hide malicious information or activity by hiding important
elements of the user interface from the user.
The status bar is a security feature of Internet Explorer windows that
provides Internet Explorer security zone information to the user. This
zone cannot be spoofed (...)" taken from Changes to Functionality in
Microsoft Windows XP Service Pack 2, Internet Explorer Window Restrictions
http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2brows.mspx#ECAA

DU

 

[Andrew Poulos]

DU wrote:

[I've snipped most of your response. Not because it isn't appreciated,
which it is, but because this is the only bit I want to comment further on.]

There is a window resizing grippy at the right end of the
Firefox/Mozilla statusbar.

1. This code gives me a window with no statusbar in FF:
var myWin = window.open("", "tinyWindow",
'toolbar=no,width=150,height=100,resizable=no');

It seems that windows with a height of less than 150px don't get a
statusbar, at least on WinXP SP1.

2. If you use the same code but with a, say, 300x300 window and the user
has turned off the statusbar in the parent window then there appears to
be no way to resize the new window nor to turn on its statusbar.

These seem to be counter to the idea of user-centricity but I do get the
gist of what people are saying. Thanks to everyone one who responded.


Andrew Poulos

 

[DU]

DU wrote:

[I've snipped most of your response. Not because it isn't appreciated,
which it is, but because this is the only bit I want to comment further
on.]

There is a window resizing grippy at the right end of the
Firefox/Mozilla statusbar.

1. This code gives me a window with no statusbar in FF:
var myWin = window.open("", "tinyWindow",
'toolbar=no,width=150,height=100,resizable=no');

Your code gives you a window with no statusbar in FF (and in MSIE 5+,
Mozilla 1.x or NS 6+ but not in MSIE 6 SV1) because as soon as you
declare the windowFeatures string list, the window features which are
not defined are removed or disabled except feature titlebar and close.
That is what will happen to an user if, of course, he did not set his
preferences to force window resizability and presence of statusbar.
Mozilla and Firefox users can force all secondary script-initiated
windows to be easily resizable by setting
dom.disable_window_open_feature.resizable
dom.disable_window_open_feature.status
to true in about:config or in their user.js file.

In theory, the minimal height for any secondary window is 100 but, in
practice, it is 150 in Mozilla-based browsers. So, here, your code will
trigger dimension compensating correction mechanism on your window.
That's bug 176320 btw.

Your code also requests implicitly to remove scrollbars even if needed,
even if the content overflows window dimensions. So, if the user has a
minimal floor font-size bigger than what you use, the window won't allow
him to access your content since you're trying so hard to remove
statusbar, window resizability and scrollbars.

It seems that windows with a height of less than 150px don't get a
statusbar, at least on WinXP SP1.

That's another bug actually.
Bug 128198: When resizing (some) windows vertically, status bar starts
to shrink when there is still lots of window space left
https://bugzilla.mozilla.org/show_bug.cgi?id=128198

2. If you use the same code but with a, say, 300x300 window and the user
has turned off the statusbar in the parent window then there appears to
be no way to resize the new window nor to turn on its statusbar.

No. I should be able to access the menubar and then View/Status Bar in
the secondary window in the Windows platform with MSIE 5+. Mozilla is
trying to implement the same by fixing
Bug 75158: `View' > `Show/Hide' menu items can't override window.open flags
http://bugzilla.mozilla.org/show_bug.cgi?id=75158

Again, if the Mozilla user has set his about:config to force statusbar
presence, window resizability and scrollbars if needed, then everything
will be rendered and your requests in the windowFeatures string list
will be ignored. Same thing with Opera 7.x and 8.0b1: the users can very
easily force presence of all toolbars and window basic, standard
functionalities.

DU

 

[DU]

Did you test it? That would have removed the doubt.



Bullshit.

If the window feature is incorrectly spelled, then the requested feature
is ignored. If there is a blank space in the windowFeatures string list,
then all requested feature after the blank space are ignored and this is
a parsing mechanism.

E.g.:
WindowObjectReference = window.open(strUrl, strWindowName,
"width=200,height=200,scrollbar=yes,resizeable=yes,statusbar=yes");
will create a 200x200 window which won't be resizable, won't have a
statusbar and won't render scrollbar(s) if content overflows window
dimensions because the features are incorrectly spelled.

Same thing with
WindowObjectReference = window.open(strUrl, strWindowName,
"width=200,height=200,scrollbars=auto,resizable=always,status=ok");
because the only window feature values are not "yes", "no", "1" or "0".

DU

 

[Andrew Poulos]

DU wrote:
[snip]

Again, if the Mozilla user has set his about:config to force statusbar
presence, window resizability and scrollbars if needed, then everything
will be rendered and your requests in the windowFeatures string list
will be ignored. Same thing with Opera 7.x and 8.0b1: the users can very
easily force presence of all toolbars and window basic, standard
functionalities.

This is all great info thanks. One 'final' comment, my MZ's about:config
displays about 1,200 entries so how is expected that ordinary people can
know about and then have the temerity to edit them?


Andrew Poulos

 

[Randy Webb]

If the window feature is incorrectly spelled, then the requested feature
is ignored. If there is a blank space in the windowFeatures string list,
then all requested feature after the blank space are ignored and this is
a parsing mechanism.

And it is the syntax error that triggers the parsing mechanism to ignore
the requested feature. If it truly ignored the syntax error then it
wouldn't skip anything, wouldn't ignore any feature specified after it.
It is the syntax error that triggers it so it's impossible that it
"simply ignores it".

 

[DU]

DU wrote:
[snip]

Again, if the Mozilla user has set his about:config to force statusbar
presence, window resizability and scrollbars if needed, then
everything will be rendered and your requests in the windowFeatures
string list will be ignored. Same thing with Opera 7.x and 8.0b1: the
users can very easily force presence of all toolbars and window basic,
standard functionalities.

This is all great info thanks. One 'final' comment, my MZ's about:config
displays about 1,200 entries so how is expected that ordinary people can
know about and then have the temerity to edit them?


Andrew Poulos

Good question, good analysis. Not new though.
"On the other hand, Firefox is [still] more a techie product requiring
frequent 'under the hood' fixes with a weird preference set called
'about:config' which is hidden to users. (...) Seventy-five percent of
the changes I needed to make to Firefox to fit my browsing habits (and
not specific to I.E.) required accessing 'about:config' and its arcane
structure and wording."
Gary Schare, Director of Windows Product Management at Microsoft,
November 16th 2004
http://www.betanews.com/article/Microsoft_Windows_Exec_Talks_IE_Security/1100619607

I think you have a point there. There should be more and better
documentation at mozilla.org. I've helped in that regard recently:
http://www.mozilla.org/docs/dom/domref/dom_window_ref76.html (updated
just 2 hours ago for the first time in 3 years)
I have a longer article in development for
http://developer-test.mozilla.org/
on this issue.

From the main page of mozilla.org, you can find easily (my assumption)
many pages giving hints, tips, support, etc.. for Firefox:

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

Personally, I think that most of these tips, support explanations should
available, accessible via the Help/Help Contents F1 files.

Overall, I also agree with + entirely support what others (Randy and
Zifud) told you: web author do not control (and shouldn't try to
control) the browser (toolbar presence, window functionalities) when in
fact it is (should be) the user who controls it.
One reason why tab-capable browsers have gained popularity is that
opening a link in a new tab usually does not bring any kind of bad
surprise. New script-initiated windows can have menubar missing,
scrollbars missing, status bar missing, and window resizability
disabled, etc.; new tabs can not be missing those functionalities or
toolbars (or at least, the toolbars which are present by default).
That's another reason why tab-browsing is preferred by a lot of users
because the normal user-interface of the browser window they prefer and
use is kept intact, remains stable.

DU

 

[DU]

Randy Webb wrote:

[snipped]

If the window feature is incorrectly spelled, then the requested
feature is ignored. If there is a blank space in the windowFeatures
string list, then all requested feature after the blank space are
ignored and this is a parsing mechanism.

And it is the syntax error that triggers the parsing mechanism to ignore
the requested feature.
Yes.

If it truly ignored the syntax error then it
wouldn't skip anything, wouldn't ignore any feature specified after it.

If I understood you correctly, that is what is happening in
Mozilla-based browsers.

E.g.:
WindowObjectReference = window.open(strUrl, strWindowName,
"width=200,height=150,menubar=ok,directories,scrollbars=1");
creates a 200x150 window with the personal bar (or Bookmarks toolbar in
Firefox or Links bar in MSIE 5+) and with scrollbar(s) if content
overflows window dimensions but there shouldn't be menubar in any
browser. Tested under Mozilla 1.8a6 build 2005011105 and MSIE 6 SV1.

OTOH, inserting a blank space in the windowFeatures string list is much
more damaging as string parsing will stop at the first occurence of a
blank space and ignore the rest of the windowFeatures list.

DU

 

[willardjones]

haven't bothered to learn where the settings are to change the
behaviour of either product.

Well, I have not changed the default settings of either MZ nor FF so for
me they do behave differently. It took me about 15 minutes to find the
setting in FF. Do you think many non-developer users even know these
settings exist?

[...]

Interestingly enough if I turn the statusbar off using the menu item
provided, then:
- new popup windows also do not have a statusbar
- the resizable=no option is now functional

So if I want to resize a popup I should, close the popup, go to the
parent page, turn the statusbar on, re-launch the popup, and then
resize the popup... bizarre.

Yes ... and no. The user can stop a script from changing the status
bar text *and*, independently, stop a script from hiding the status bar
itself.

Status bar text??? Let me rephrase the question, so what does the
visibility of the statusbar in FF have to do with whether or not the
user can resize the window?

Learn about the application first, then you can comment intelligently.

I'm trying to learn about the application, that's why I'm asking
questions. Though I did not note anywhere in the press release that FF
prevented certain scripts from running:
<url:http://www.mozilla.org/products/firefox> but it does say that it's
a "Developers Best Friend".
Andrew Poulos

Thanks!

(e-mail address removed)