toolbar.visible does not operate

[DEN]

Hello,
I need to remove toolbar and menubar from my current window (not opened
with window.open, it would be too easy!!!).
I've tried to use the window.toolbar.visible=false property,
but it has no effect.
No error message in the javascript console, nor any effect on the
current window.
I've tried Firefox and IE, same effect....
What should I do

 

[Daniel Kirsch]

I've tried to use the window.toolbar.visible=false property,
but it has no effect.

IIRC This "feature" was removed from Mozilla, you cannot change the
visibility property anymore. window.toolbar was never a scriptable IE
element.

Daniel

 

[Martin Honnen]

DEN wrote:

I need to remove toolbar and menubar from my current window (not opened
with window.open, it would be too easy!!!).
I've tried to use the window.toolbar.visible=false property,
but it has no effect.
No error message in the javascript console, nor any effect on the
current window.
I've tried Firefox and IE, same effect....

With IE you should get a script error as window.toolbar is undefined. As
for Firefox only privileged script is allow to perform such changes so
you would need to sign your script and then ask for the privilege e.g.

netscape.security.PrivilegeManager.enablePrivilege('UniversalBrowserWrite');
window.toolbar.visible = false;

 

[DEN]

Martin Honnen a écrit :

DEN wrote:




With IE you should get a script error as window.toolbar is undefined. As
for Firefox only privileged script is allow to perform such changes so
you would need to sign your script and then ask for the privilege e.g.

netscape.security.PrivilegeManager.enablePrivilege('UniversalBrowserWrite');

window.toolbar.visible = false;

Thanks for this answer,
but as IE is the most used,
does someone know the way to do it for any browser ?
Thanks again
DEN

 

[Grant Wagner]

Martin Honnen a écrit :
Thanks for this answer,
but as IE is the most used,
does someone know the way to do it for any browser ?

The answer you seek was already explained above your reply. To do this
in Firefox or other Gecko-based browsers you do:

netscape.security.PrivilegeManager.enablePrivilege('UniversalBrowserWrite');
window.toolbar.visible = false;

But:

- if you attempt to do this locally, the user will get a big scary
dialog explaining that a script is about to do something scary and ask
the user if they really want to let the script do this scary thing
- if you attempt to do this from an untrusted Web site the request to
enablePrivilege() will simply be denied

You will need to sign your script (by a certificate) for it to run
without prompts and denial, and then it will only work on the
Gecko-based family of browsers. That's a lot of work and expense to do
something that won't work on all the browsers you expect to support.

Rethink your design.

 

[Thomas 'PointedEars' Lahn]

[...] netscape.security.PrivilegeManager.enablePrivilege('UniversalBrowserWrite');
window.toolbar.visible = false;

But:

- if you attempt to do this locally, the user will get a big scary
dialog explaining that a script is about to do something scary and ask
the user if they really want to let the script do this scary thing [...]

Instead of the FUDish term "scary", the more reasonable and really
used term "potentially dangerous" and the like should also be used
here, especially in an explanation for beginners.


PointedEars

 

[Thomas 'PointedEars' Lahn]

[...] netscape.security.PrivilegeManager.enablePrivilege('UniversalBrowserWrite');
window.toolbar.visible = false;

But:

- if you attempt to do this locally, the user will get a big scary
dialog explaining that a script is about to do something scary and ask
the user if they really want to let the script do this scary thing [...]

Instead of the FUDish term "scary", the more reasonable and really
used term "potentially harmful" and the like should also be used
here, especially in an explanation for beginners.


PointedEars

 

[Randy Webb]

Grant Wagner wrote:

[...]
netscape.security.PrivilegeManager.enablePrivilege('UniversalBrowserWrite');

window.toolbar.visible = false;

But:

- if you attempt to do this locally, the user will get a big scary
dialog explaining that a script is about to do something scary and ask
the user if they really want to let the script do this scary thing [...]

Instead of the FUDish term "scary", the more reasonable and really
used term "potentially harmful" and the like should also be used
here, especially in an explanation for beginners.

Oh bullshit. Learn to handle reality.

 

[Dr John Stockton]

JRS: In article <[email protected]>, dated Sun, 26
Jun 2005 13:14:12, seen in Thomas

- if you attempt to do this locally, the user will get a big scary
dialog explaining that a script is about to do something scary and ask
the user if they really want to let the script do this scary thing [...]

Instead of the FUDish term "scary", the more reasonable and really
used term "potentially harmful" and the like should also be used
here, especially in an explanation for beginners.

One should not criticise foreigners for loose or colloquial use of
English, especially when one is oneself an error-prone foreigner.

 

[Grant Wagner]

[...] netscape.security.PrivilegeManager.enablePrivilege('UniversalBrowserWrite');
window.toolbar.visible = false;

But:

- if you attempt to do this locally, the user will get a big scary
dialog explaining that a script is about to do something scary and
ask
the user if they really want to let the script do this scary thing
[...]

Instead of the FUDish term "scary", the more reasonable and really
used term "potentially harmful" and the like should also be used
here, especially in an explanation for beginners.

I was using the term "scary" deliberately and repeatedly to exaggerate
the fact that the script shown has a serious drawback (in addition to
the fact that it does not work in the default security environment of
Internet Explorer on Internet Web sites). That drawback is that it
requires end-user interaction that will most likely (hopefully) result
in most users choosing to not allow the script to continue running.

Teaching end-users that it is okay to agree to this prompt is a mistake,
and will lead to end-users taking other actions that would be
ill-advised.

 

[Thomas 'PointedEars' Lahn]

[...]

netscape.security.PrivilegeManager.enablePrivilege('UniversalBrowserWrite');

window.toolbar.visible = false;

But:

- if you attempt to do this locally, the user will get a big scary
dialog explaining that a script is about to do something scary and
ask
the user if they really want to let the script do this scary thing
[...]

Instead of the FUDish term "scary", the more reasonable and really
used term "potentially harmful" and the like should also be used
here, especially in an explanation for beginners.

I was using the term "scary" deliberately and repeatedly to exaggerate
the fact that the script shown has a serious drawback

As there is no alternative other than not doing it, and it could be
required in some cases, I would certainly not call it a drawback.

(in addition to the fact that it does not work in the default security
environment of Internet Explorer on Internet Web sites).

Which carries not much weight, considering the security flaws
Internet Explorer has presented us with in previous versions.

That drawback is that it requires end-user interaction that will most
likely (hopefully) result in most users choosing to not allow the script
to continue running.

If they decide so, great. I see no harm in that.

Teaching end-users that it is okay to agree to this prompt is a mistake,
and will lead to end-users taking other actions that would be
ill-advised.

Disagreed. Teaching end users to read and attempt to understand each and
every dialog they are exposed to before doing anything else is certainly
the better approach; as you called it "scary": fear is not per se a Bad
Thing. Besides, end users are not subscribed to this newsgroup, are they?
The wording was just inappropriate for a developer's newsgroup.


PointedEars

 

[Grant Wagner]

Which carries not much weight, considering the security flaws
Internet Explorer has presented us with in previous versions.

I fail to see how past vulnerabilities have anything to do with a script
sample that will not execute in the default Internet Explorer security
environment without end-user interaction.

Or are you suggesting that the use of script that does not currently
work in the default security environment without end-user interaction,
but may some day work due to a yet to be discovered vulnerability is
proper design?

If they decide so, great. I see no harm in that.

What a strange statement to make. You see no harm in designing and
developing script on which the functionality of your site depends, but
which you hope will never be executed by the target audience?

Disagreed. Teaching end users to read and attempt to understand each
and
every dialog they are exposed to before doing anything else is
certainly
the better approach; as you called it "scary": fear is not per se a
Bad
Thing. Besides, end users are not subscribed to this newsgroup, are
they?

I do not know who, or how many people we may consider "end-users" may
subscribe to this newsgroup, and neither do you. Any speculation by
either of us would be just that, speculation. But that's entirely
irrelevant.

No one should be encouraging end-users to agree to potentially dangerous
actions.

The situation is analogous to the mytical IT manager who sent out an
E-mail advising everyone not to click on attachments, then attached a
virus scanner which he requested users run to ensure their systems were
not already infected.

The wording was just inappropriate for a developer's newsgroup.

In much the same way that comments such as the following are
inappropriate for a developer's newsgroup?

=== Begin example 1 ===

[...] Thomas 'PointedEars' Lahn [...] posted :

No, read <http://en.wikipedia.org/wiki/UTC>.

Once more, Pooh, you are stupidly answering an old article in respect
of
a point which is already adequately covered in subsequent discussion.
[flame]

Get a life.


PointedEars

=== End example 1 ===

=== Begin example 2 ===

thank for help, but i really don't know who to start.

Try yourself.


SCNR

PointedEars

=== End example 2 ===

 

[Thomas 'PointedEars' Lahn]

"Thomas 'PointedEars' Lahn" [...] wrote [...]

Which carries not much weight, considering the security flaws
Internet Explorer has presented us with in previous versions.

I fail to see how past vulnerabilities have anything to do with a script
sample that will not execute in the default Internet Explorer security
environment without end-user interaction.

Since the software is inherently insecure, there is a high probability of
present and future security flaws. Therefore I don't care much about IEs
security "concept". In fact I hope that it will be replaced ASAP
throughout the Web.

Or are you suggesting that the use of script that does not currently
work in the default security environment without end-user interaction,
but may some day work due to a yet to be discovered vulnerability is
proper design?
No.


What a strange statement to make. You see no harm in designing and
developing script on which the functionality of your site depends,
but which you hope will never be executed by the target audience?

The functionality of the site does not depend on this particular feature.
But if someone wants the feature applied to his UA, it is a Good Thing
that it is asked for before if it is addressed because of the other users
that do not want it.

I do not know who, or how many people we may consider "end-users" may
subscribe to this newsgroup, and neither do you.

Exactly, and that was merely a rhetoric question.

Any speculation by either of us would be just that, speculation.

No, from experience alone, there is a high probability that
end-users, especially IE end users, will not read this thread.

But that's entirely irrelevant.

No, it is not. When referring to a matter Wording should be chosen
according to the probable target audience and according to the context.

No one should be encouraging end-users to agree to potentially dangerous
actions.

And nobody suggested that, on the contrary.

The wording was just inappropriate for a developer's newsgroup.

In much the same way that comments such as the following are
inappropriate for a developer's newsgroup?
[...]

Oh, an ad hominem attack.


PointedEars