window objects (locationbar, statusbar, etc) visible property cannot be changed

VERIFIED FIXED

Status

()

P2
normal
VERIFIED FIXED
19 years ago
18 years ago

People

(Reporter: dannyg, Assigned: danm.moz)

Tracking

Trunk
x86
Other
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [rtm++])

(Reporter)

Description

19 years ago
In M17 with prefs set for codebase principals:
   pref("signed.applets.codebase_principal_support", true);
and using UniversalBrowserWrite permission, setting the visible property of the
following objects does not stick nor does it change the actual visibility of the
window chrome piece:

window.directories (*)
window.locationbar
window.menubar
window.personalbar
window.scrollbars
window.statusbar
window.toolbar

All but (*) were available in NN4 with signed scripts or codebase principles
turned on. With codebase principles turned on, no exceptions are thrown.
(Reporter)

Comment 1

19 years ago
Here is a NN4 example (from JSBible 3) that also manages (for no apparent
reason) to throw an uncaught exception in M17 as the page loads, but it is an
example to aspire to for moz:

<HTML>
<HEAD>
<TITLE>Bars Bars Bars</TITLE>
<SCRIPT LANGUAGE="JavaScript">
// store original outer dimensions as page loads
var originalLocationbar = window.locationbar.visible
var originalMenubar = window.menubar.visible
var originalPersonalbar = window.personalbar.visible
var originalScrollbars = window.scrollbars.visible
var originalStatusbar = window.statusbar.visible
var originalToolbar = window.toolbar.visible

// generic function to set inner dimensions
function toggleBar(bar) {
    netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserWrite")
    bar.visible = !bar.visible
    netscape.security.PrivilegeManager.revertPrivilege("UniversalBrowserWrite")
}
// restore settings
function restore() {
    netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserWrite")
    window.locationbar.visible = originalLocationbar
    window.menubar.visible = originalMenubar
    window.personalbar.visible = originalPersonalbar
    window.scrollbars.visible = originalScrollbars
    window.statusbar.visible = originalStatusbar
    window.toolbar.visible = originalToolbar
    netscape.security.PrivilegeManager.revertPrivilege("UniversalBrowserWrite")
}
</SCRIPT>
</HEAD>
<BODY onUnload="restore()">
<FORM>
<B>Toggle Window Bars</B><BR>
<INPUT TYPE="button" VALUE="Location Bar"
onClick="toggleBar(window.locationbar)"><BR>
<INPUT TYPE="button" VALUE="Menu Bar" onClick="toggleBar(window.menubar)"><BR>
<INPUT TYPE="button" VALUE="Personal Bar"
onClick="toggleBar(window.personalbar)"><BR>
<INPUT TYPE="button" VALUE="Scrollbars" onClick="toggleBar(window.scrollbars)"><BR>
<INPUT TYPE="button" VALUE="Status Bar" onClick="toggleBar(window.statusbar)"><BR>
<INPUT TYPE="button" VALUE="Tool Bar" onClick="toggleBar(window.toolbar)"><BR>
<HR>
<INPUT TYPE="button" VALUE="Restore Original Settings" onClick="restore()"><BR>
</FORM>
</BODY>
</HTML>
Reassigning to DOM for further analysis. I don't think the security manager is
the problem here. Are these even supposed to work as before? Do they work on the
fly, or only when a new window is opened?
Assignee: mstoltz → jst
Status: UNCONFIRMED → NEW
Component: Security: General → DOM Level 0
Ever confirmed: true
QA Contact: czhang → desale
Target Milestone: --- → M19
Assignee: jst → danm
Reassigning to Dan who's working in this area...
(Assignee)

Comment 4

19 years ago
  Yes, they're supposed to work on the fly. The problem is, while Travis was 
pushing around braces and indentation in nsBarProps.cpp, he also changed some 
code for some reason. Reverting this odd line (line 247 of nsBarProps.cpp rev 
1.8)

         chromeFlags |= ~aChromeFlag;
to its original
         chromeFlags &= ~aChromeFlag;

fixes this problem. (For the most part -- the actual implementation of certain 
properties (menubar.visible on Windows, for instance) is broken.)

But this is a safe change. We should probably fix it. Nominating rtm.
Status: NEW → ASSIGNED
Keywords: rtm
(Assignee)

Updated

19 years ago
Whiteboard: fix in hand

Comment 5

19 years ago
rtm+ need info.  one-liner to fix regression, Nav 4.x compatibility issue.
Priority: P3 → P2
Whiteboard: fix in hand → [rtm+ need info] fix in hand

Comment 6

19 years ago
Yep, looks like a no-brainer. sr=waterson.
Fine with me, r=jst
(Assignee)

Updated

19 years ago
Whiteboard: [rtm+ need info] fix in hand → [rtm+]

Comment 8

19 years ago
PDT marking [rtm++]
Whiteboard: [rtm+] → [rtm++]
(Assignee)

Comment 9

19 years ago
checked in, trunk & netscape rtm branch
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 10

19 years ago
Verified with 2000-10-16-09.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.