Closed Bug 55858 Opened 24 years ago Closed 11 years ago

add more "bar" objects to the window object

Categories

(Core :: DOM: Core & HTML, enhancement, P4)

enhancement

Tracking

()

RESOLVED WONTFIX
Future

People

(Reporter: bugzilla, Unassigned)

References

()

Details

(Keywords: dom0)

Currently Mozilla has a "toolbar" object and a "window.statusbar" object.
But what about the another bars, like "Personal toolbar", "Taskbar" and 
"Sidebar".
Those bars should also have some kind of objects.
What about just making a general toolbar object with:
toolbar.navigation
toolbar.personal
toolbar.task
toolbar.side
etc...?
There also seems to be some kind of "directories" object which has a visible 
property...
http://gemal.dk/browserspy/showprop.html?window.directories
This is something that could be looked into sometime, but not now. --> Future.
Status: NEW → ASSIGNED
Priority: P3 → P4
Summary: more "bar" objects → [FEATURE]more "bar" objects
Target Milestone: --- → Future
Keywords: dom0
http://developer.netscape.com/docs/manuals/communicator/jsref/win1.htm#1187502

some "bar" objects in 4x:
self.menubar
self.toolbar
self.locationbar
self.personalbar
self.scrollbars
self.statusbar
Dan, here's one more bug that you could look into whenever you get time to :-)
Assignee: jst → danm
Status: ASSIGNED → NEW
The current list is: directories (personalbar), locationbar, menubar, scrollbars, 
statusbar and toolbar. They're a kind of uncomfortable oddity, having only one 
property as they do, and being basically inapplicable to a fluid xml-based UI. 
And there is that compatibility thing where you'd have to check to see whether 
you were in Mozilla before tweaking a new property. But despite all that, we 
should look into adding sidebar and taskbar, yes. (Any others?)
I wonder if this bug is realistic or serving some worthy purpose. Right now, the
only toolbars which are not detectable, measurable, accessible or scriptable (in
some way) are
- Site Navigation Bar
- Tab Bar
- Component Bar

If you dynamically hide the personalbar via script, then the Site Navigation Bar
will also disappear.

If you dynamically hide both toolbar and locationbar via script, then the Tab
Bar will also disappear.

And the Component Bar is obviously dependent of the statusbar visibility.

The taskbar is os-dependent, relative to the os. So, I really do not see how/why
the taskbar has/should have anything to do or any kind of script
incidence/interaction with the [browser] window object.

The sidebar content itself is not accessible via script (anyway, why should it be?):
http://www.mozilla.org/docs/dom/domref/dom_window_ref116.html#1021451 
The notes section says:
"The sidebar is a subframe in the DOM of the application window. Its content can
be accessed with sidebar._content"
_content always refers to the main browser content window (as a target) serving
to display the referenced links in the sidebar.

One can add a tab within the sidebar:
window.sidebar.addPanel(strTitle, strUrlContent, strCustomize);
http://devedge.netscape.com/viewsource/2002/sidebar/#adding

Making chrome UI elements scriptable often leads to misuse, excessive web
designer [invasive, intrusive] control and abuse of all sorts where the ordinary
user experience irritation, powerlessness, feeling overwhelmed. Besides
visibility (boolean property visible), I do not see what more web designers
would need to know and/or would justifiably need to be able to script on the
user's chrome UI elements.

All I can see as a justifiable, worthy additional feature could be a boolean
"expanded" property for the sidebar just to ease the process of adding a tab
into the sidebar.

if(window.sidebar)
    {
    if (window.sidebar.expanded)
       {
       window.sidebar.addPanel(strTitle, strUrlContent, strCustomize);
       }
    else
       {
       alert("You need to have My Sidebar panel opened before you attempt to add
a new tab."); return false;
       };
    }
    else
    {
    var rv = window.confirm ("Sidebar is a feature supported by Mozilla 1.0+ and
Netscape 6+. \r" + "Would you like to upgrade now?");
    if (rv)
         document.location.href =
"http://channels.netscape.com/ns/browsers/default.jsp";
    };
Implementing this in an embedding environment is a pain (different browsers have
different bars), and I don't really think pages should be getting this
information anyway, so I would vote wontfix here....
I agree to WONTFIX this bug. 
One small detail remains: would it be possible to implement "expanded" as a
property of window.sidebar?
Assignee: danm.moz → nobody
Severity: normal → enhancement
Summary: [FEATURE]more "bar" objects → add more "bar" objects to the window object
Filter on "Nobody_NScomTLD_20080620"
QA Contact: desale → general
Given the state of the Web (and the browser) nowadays, this is unlikely to happen.

Resolving WONTFIX per comment 7 and comment 8.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.