Open Bug 55820 Opened 23 years ago Updated 6 months ago

"toolbar.visible" is true even when Navigation toolbar isn't shown, same for statusbar.visible

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
All
Type:
defect

Tracking

()

Milestone:
Future

People

(Reporter: bugzilla, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: dom0) 

In Netscape 4.75 the object:
"toolbar.visible"
showed the status of whether the user had the Navigation toolbar on or off.
The value is always true in Mozilla even when the Navigation toolbar is turned 
off.

Try turning the Navigation toolbar on and go to:
http://gemal.dk/browserspy/showprop.html?toolbar
now turn is off and reload...
Dan, could you look into this?
Assignee: jst → danm
Closing WFM: the toolbar.visible property is behaving correctly for me in 
today's build. The example given by the reporter is hard to follow. The 
following HTML snippet works as expected in Mozilla:

<html><head><script>
  function showToolbarStatus() {
    var node = document.getElementById("toolbarstatus");
    node.firstChild.data = toolbar.visible ? "true" : "false";
  }
  function toggleToolbarStatus() {
    netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserWrite");
    toolbar.visible = !toolbar.visible;
  }
</script></head>
<body onload="showToolbarStatus()">
<form>
  <input type=button value="toggle toolbar visibility"
   onclick="toggleToolbarStatus()">
  <input type=button value="update toolbar status display"
   onclick="showToolbarStatus()">
</form>
<br>
toolbar.visible is
<div style="display:inline" id="toolbarstatus">uninitialized</div>
</body></html>
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Here's how to reproduce:
1) Verify that all toolbars are on in "View->Toolbars"
2) Load http://gemal.dk/browserspy/showprop.html?toolbar
3) The page should show "visible-true-boolean"
4) Turn of navigation toolbar by unchecking "View->Toolbars->Navigation 
toolbar"
5) Reload page
6) The page will now still show "visible-true-boolean"

Expected:
The page would show "visible-false-boolean" after the reload, since the 
navigation toolbar isn't visible!
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
  Alright. The problem is, then, that the window.toolbar.visible property isn't 
updated by the code behind the View -> Toolbars -> Navigation Toolbar menu, as it 
is in Nav 4.0. Reassigning to the owner of utilityOverlay.js for evaluation.
  NB Ben: altering that property directly works as expected, so I wouldn't call 
this a DOM 0 conformance issue.
Assignee: danm → ben
Status: REOPENED → NEW
There is a similar issue with the Personal Toolbar: for instance, go to
www.startpagina.nl and select a random link. The newly created window will have
no personal toolbar. You can't activate it again by toggling View > Toolbars >
Personal Toolbar.
Keywords: dom0
Status: NEW → ASSIGNED
Target Milestone: --- → Future
A few days ago, I filed bug 155660 which is the same thing as this bug except it
involves the statusbar.

I wish we could merge both bugs into 1 bug and increase its priority and set its
target to Moz1.2 or so. Navigation Toolbar and Status Bar both can be
checked/unchecked via View-Show/Hide and they both fail while being evaluated
via a script. So,

window.toolbar.visible
window.personalbar.visible <= I haven't verify that one
window.statusbar.visible

would be merged into 1 bug.

Just my opinion here.

I'll take this one too.
Assignee: ben → caillon
Status: ASSIGNED → NEW
Personalbar.visible does not get updated either: so that makes 3 bars which
visibility value can be set via View-Show/Hide and whose visibility value can
not be gotten via javascript.
Assignee: caillon → general
QA Contact: desale → ian
Implementing this in an embedding environment is a pain, and I don't really
think pages should be getting this information anyway, so I would vote wontfix
here....
If we WONTFIX this we need to at least decide on a policy. Is our policy that
these three attributes will be read/write boolean fields initialised to "true"
but otherwise having no magical properties whatsoever?
I agree to WONTFIX this bug and WONTFIX bug 155660 as well.

If web developers focus on creating scalable webpages, then their scripts don't
need to know/access the info of presence or absence of this or that toolbar.
Even right now, several toolbars can be present but collapsed thanks to
grippies; so even now, at best, scripts and web developers would have false,
unreliable info about their presence.

If they really need to set or work with secondary window's dimensions, they can
set outerHeight and outerWidth as 2 of the many windowFeature of the 3rd
parameter of window.open().

Personally I would remove the attributes themselves: if you leave them and
pre-assign/initialize them to true, web developers might assume they exist for
them to use and/or they would eventually file bugzilla bugfiles on them.
Assignee: general → nobody
QA Contact: ian → general
> I don't really think pages should be getting this information anyway, so I 
> would vote wontfix here....

FWIW, current draft of the HTML5 spec says:

> The visible attribute, on getting, must return either true or a value 
> determined by the user agent to most accurately represent the visibility
> state of the user interface element that the object represents, as described
> below. On setting, the new value must be discarded.

<http://dev.w3.org/html5/spec/Overview.html#browser-interface-elements>
merging with bug 155660, since they're not really different.
Summary: "toolbar.visible" is true even when Navigation toolbar isn't shown → "toolbar.visible" is true even when Navigation toolbar isn't shown, same for statusbar.visible
Since the HTML specifications suggests that window.statusbar.visible should
return true when the statusbar is visible and false when the statusbar is
hidden, it must be an essential parameter of the window object. If it is not
feasible , please suggest how to identify if the status bar is hidden or
visible in Firefox. In Safari, we are able to determine the existence of
statusbar using window.statusbar.visible.
Bulk priority change, per :mdaly
Priority: P3 → P5
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.