Closed Bug 54235 Opened 24 years ago Closed 24 years ago

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

Categories

(Core :: DOM: Core & HTML, defect, P2)

x86
Other
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: dannyg, Assigned: danm.moz)

Details

(Whiteboard: [rtm++])

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.
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...
  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
Whiteboard: fix in hand
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
Yep, looks like a no-brainer. sr=waterson.
Fine with me, r=jst
Whiteboard: [rtm+ need info] fix in hand → [rtm+]
PDT marking [rtm++]
Whiteboard: [rtm+] → [rtm++]
checked in, trunk & netscape rtm branch
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
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.