If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

[RFE] Hide/show toolbars button in title bar

VERIFIED FIXED in mozilla1.0


UI Design
17 years ago
9 years ago


(Reporter: hsivonen, Assigned: Robert John Churchill)



Mac OS X

Firefox Tracking Flags

(Not tracked)




(2 attachments, 4 obsolete attachments)



17 years ago
On Mac OS X, Finder and Mail have a hide/show toolbar button in the window title
bar on the right.

The same kind of hide/show toolbars button would be a logical addition to
Mozilla's browser window title bar. (Currently there is no way to quickly toggle
the visibility of all toolbars at one.)

Comment 1

17 years ago
What do other macheads/ui people think?
could be cool (but only for OSX). how do we tell the OS to put that button into 
the toolbar?
"...button into the toolbar?"

doh, I meant titlebar.
wouldn't this be a dup of bug 22056? [or, maybe dependent on it?]

Comment 5

17 years ago
No, this bug and bug 22056 are completely unrelated.

Putting buttons for non-windowing operations in the window title bar is 
generally a bad idea -- but hey, that's Mac OS X. Doing this will make us more 
consistent with other OS X apps, and it won't make us any *less* usable (unlike 
some other platform-consistency bugs I could mention).

Comment 6

17 years ago
Hoping Dan ``the window man'' Matejka can provide some insight on how to go 
about doing this.

Comment 7

17 years ago
I'm a Windows freak. -> danm, unless some machead wants to take this.
Assignee: blakeross → danm

Comment 8

17 years ago
The new IE preview has this. (OmniWeb has this, too.)

Comment 9

17 years ago
for those of us who don't have os x, some pictures are in order.
which has the widget everyone is talking about.

i'm still searching for the api.

Comment 10

16 years ago
In the Finder, getting rid of the toolbar is called "Single Document Mode." This
feature is "Under Evaluation" in the Carbon docs.




Here's the Cocoa documentation on toolbars.


Can we make Cocoa toolbox calls, or only Carbon?

- Adam
we can only make carbon calls building the way we are (CFM binary).

Comment 12

16 years ago
Well, there's got to be a way. Finder and IE are both Carbon, and they're doing it.

- Adam

Comment 13

16 years ago
The Quartz Primer document has some sample wrapper code for accessing the Core
Graphics API from a CFM Carbon app. I wonder if the window server could be
instructed to put the button there that way.


16 years ago
Target Milestone: --- → mozilla1.0
QA Contact: sairuh → claudius

Comment 14

16 years ago
Im all for it FYI

Comment 15

16 years ago
I'll take this bug (since I now have it working in my tree)...
--> rjc
Assignee: danm → rjc

Comment 17

16 years ago
Created attachment 54947 [details] [diff] [review]
"ontoolbar" event support in XUL/JS

Comment 18

16 years ago
Created attachment 54949 [details] [diff] [review]
"ontoolbar" event changes in Content/DOM/Layout & Widget(Mac)

Comment 19

16 years ago
Created attachment 54950 [details]
"ontoolbar" event support - new cpp file and headers (on Mac, add cpp file into content.cpp)

Comment 20

16 years ago
Created attachment 54951 [details] [diff] [review]
"ontoolbar" event support - makefile/MANIFEST changes

Comment 21

16 years ago
Anyone want to try out these changes?

I've added an "ontoolbar" event (which is generated under Mac OS X when the 
window's "toolbar" widget is clicked on).  The code path is modeled after how the 
"onclose" event works, BTW... widget code sends the event through the DOM to be 
handled by JavaScript registered on the <window> element.

I added "ontoolbar" handlers to most of the windows in the product:  browser, 
editor, messenger, mail compose, addressbook, bookmarks, history, etc.

Comment 22

16 years ago
Note:  its a shame that the various toolbars in the product aren't better 
architected, it would be nice to have better support for this sort of thing... 
for example, instead of specific JS for each window, having generic XBL for this 
would be nice.  (If anyone wants to go down that path, I say "go for it".)

Comment 23

16 years ago
Note: On Mac, add the new .cpp file into the content.mcp project  [not 
content.cpp]  :)

Comment 24

16 years ago
cc: hyatt for comments on the future of XUL toolbars?


16 years ago
Attachment #54949 - Attachment description: "ontoolbar" event changes in Content/DOM/Layout → "ontoolbar" event changes in Content/DOM/Layout & Widget(Mac)

Comment 25

16 years ago
I don't see the need for adding a builtin DOM event like this.  We now have
support for custom DOM events, and I don't think the huge quantities of code to
add this event (just so that it can be supported using the onfoo syntax) are

For an example of how to create a custom DOM event, see SetTitle over in
nsHTMLDocument.  I fire a DOMTitleChanged event there.  It only takes 3-4 lines
of code now to fire an event name of your choice.

This patch can basically be way way smaller.

Comment 26

16 years ago
Looking further, I don't even understand the need for a custom DOM event.  You
could just add a single function to nsWebShellWindow/nsXULWindow that fields the
NS_TOOLBAR event and toggles the toolbars' visibility.

Comment 27

16 years ago
You can toggle the toolbars' visibility just by setting an attribute on the
<window> element. We already have to do this to support toolbars=no via window.open.

Comment 28

16 years ago
David:  that doesn't work for showing/hiding the sidebar, right?

Comment 29

16 years ago
Hmmm... David says it does.  I'll give it a try.   :)

Comment 30

16 years ago
So, I made David's suggested changes... they work, not requiring any of the DOM
changes that I previously made.

However, sore points:

Some CSS weirdnesses: mail window toolbar doesn't display text under toolbar
icons, splitters are sometimes hidden, etc.  All major windows with toolbars
need tweaks.

As long as all the toolbars are hidden due to the window's toolbar windoid, the
user can't get any of the toolbars back until the toolbar windoid is clicked
again. By that, I mean that any of the options under the "View" menu such as
"Show Navigation Toolbar" won't do anything.

Also, the menu items will be "checked" as they were previously before being all

Basically, doing it this way disconnects the "View->Toolbar" menu items from the
UI when the window's toolbar windoid is clicked... until the window is clicked
again to undo the damage.

Comment 31

16 years ago
Would it work to do a getElementById for the required View->Toolbar menu items 
and invoke the commands associated with any that were visible so as to toggle 
them to invisible. You'd have to deal with tristate menus toolbars like the 
SiteNavigation bar.

If this works then the menu UI would at least be consistent, though obviously you 
can't avoid that when you turn the toolbars back on you would turn them *all* on, 
not just the ones that were previously showing.

hrm. I think that last point would annoy people a lot. Perhaps you *do* have to 
keep which ones were showing somewhere so you can restore them...

Comment 32

16 years ago
Actually, I had a better idea. Why not ignore Show/Hide toolbars and instead 
collapse them. You know, like when you click the grippy at the end of the toolbar 
so it becomes a thin line?

You'd only then have to do it to those toolbars which are visible, and the user 
has 2 highly accessible ways of undoing it (click the grippy on a case by case 
basis or click the window toolbar widget to restore all). It stores its own state 
too because the toolbars you need to restore are those that are collapsed.

If you find a mixed case where some are collapsed and some are not, the simplest 
thing to do is probably 

first click -> collapses everything which isn't collapsed
second click -> uncollapses everything

Or you could reverse that...


Comment 33

16 years ago
Adding dependancy on bug # 75742 
Depends on: 75742

Comment 34

16 years ago
Created attachment 58167 [details] [diff] [review]
XUL, CSS and JS diffs - global chrome/toolbar 

XUL, CSS and JS diffs - make chrome/toolbar styles and handling uniform across
the app


16 years ago
Attachment #54947 - Attachment is obsolete: true
Attachment #54949 - Attachment is obsolete: true
Attachment #54950 - Attachment is obsolete: true
Attachment #54951 - Attachment is obsolete: true

Comment 35

16 years ago
Created attachment 58168 [details] [diff] [review]
C++, header, and IDL changes for Mac OS X toolbar widget support

C++, header, and IDL changes for Mac OS X toolbar widget support

Comment 36

16 years ago
These last two patches build upon what David recommended.  Basically, make all 
the "chromeclass" styles uniformly global across the app.

Reviews needed, especially from Hyatt due to changes to the locked-down CSS files 
(navigator.css items moved to global xul.css)
why two separate calls to ::ChangeWindowAttributes()? Seems redundant.

Comment 38

16 years ago
Pink:  indeed, looks like I forgot to delete the first call when I moved it (to 
where the second one is)

Comment 39

16 years ago
Robert, I need to know what you decided as far as breaking the View-->Show/Hide
menu (this will save you getting several bugs).

For my .02 I love this feature but there is no sense copying a feature if we're
just going to emulate it poorly. I looked at the way the finder handles it and
saw that it is smooth but probably mostly because there is only one toolbar so
show/hide can follow each other w/o trouble in that case. That gave me an idea.

Add a new menuitem View-->Show/Hide-->"All toolbars"
This item could be the first menuitem in the list.
This menuitem would always be active. The trick is after you've clicked the
freaky button(you call it a 'windoid') to hide the toolbars this menuitem would
be the _only_ active one in the show/hide menu. Selecting it would bring back
your toolbars and activate the other items.

This sol'n gives you only one thing to hook up that can track 1-to-1 with the
freaky button state and we can ignore the case of getting into a weird some on/
some off situation. AND it's a cross platform sol'n - no platform would suffer
from having an all on/off menuitem even if they didn't have the corresponding
freaky button.

Comment 40

16 years ago
Claudius:  the View-->Show/Hide menus are already broken in some cases and need
to be fixed up by their respective component owners anyway, so it isn't a big

Comment 41

16 years ago
Was my idea of collapsing the toolbars instead so off base? 

I still think it solves all of the concerns and no one seems to have poked any 
holes in it...

Comment 42

16 years ago
Has anyone revealed the latest changes based upon David's comments?  <sigh>  I
guess not.  His method requires virtually no code bloat.

Comment 43

16 years ago
revealed=reviewed, of course

Comment 44

16 years ago
robert: while I am far from the arbitor of good coding practices, that is
soooooo not an excuse to knowingly break it further. Especially if, as I
believe(sez me who does not write code) there is a workable alternate sol'n.

lordpixel: first off your sol'n doesn't really get rid of the toolbars. Leaving
a little collapsed bar would just annoy me. It just a 90% sol'n.
  Secondly, uncollapsing all of the toolbars when that's not how I left them
before I clicked the freaky button is wrong and confusing and bad and other
negative adjectives and the only way around that is adding a fair bit of code
that nobody wants to do.
  Thirdly, without the behavior being hooked up to the View menu (as it should
be) the menu will still appear broken to jane user, and we'll have to always
explain "no, that's just how it works". Those are my thoughts.

Of course I'm biased but I thought Show/Hide-->All Toolbars was a pretty eff'n
sweet idea :-) AND it gives the benefit to all platforms.

Comment 45

16 years ago
Claudius: don't give me any crap, or I'll come over to your cube.

Comment 46

16 years ago
ok rjc is not evil (he really did come over to my cube). I'll withdraw my
objections and we'll work together to file bugs on 'other people' when this fix
gets in. At some point I'll also write the rfe for the Show/Hide All Toolbars.
It should be noted that I still think I'm right. It's just that rjc isn't so
wrong anymore.

Comment 47

16 years ago

Comment 48

16 years ago

Comment 49

16 years ago
verbal r=ben

Comment 50

16 years ago
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 51

16 years ago
There are still problems with this implementation as of the 10/27/01 trunk
build. Many top level windows which do not have toolbars like the 'View Source'
and 'Page Info' windows.

Comment 52

16 years ago
Just a quick note on the JS diffs (for next time, perhaps?)
Some of the code uses the "all" window style.
In this case you don't need to explicitly add "status" or "toolbar" styles.

Comment 53

16 years ago
Note: the "all" style only applies to window.openDialog, not window.open
Does anyone know why the JS console opens without scrollbars, you need to resize
the window to make them appear? (Or
window.openDialog("chrome://global/content/console.xul", "_blank",
"chrome,all,dialog=no") also works.)
mass-verifying claudius' Fixed bugs which haven't changed since 2001.12.31.

if you think this particular bug is not fixed, please make sure of the following
before reopening:

a. retest with a *recent* trunk build.
b. query bugzilla to see if there's an existing, open bug (new, reopened,
assigned) that covers your issue.
c. if this does need to be reopened, make sure there are specific steps to
reproduce (unless already provided and up-to-date).


[set your search string in mail to "AmbassadorKoshNaranek" to filter out these
Product: Core → Mozilla Application Suite


9 years ago
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.