171702 - Add support for a <toolbar> to the right of the menu bar

Status: VERIFIED FIXED

(Firefox :: Toolbars and Customization, enhancement)

Description

[djk]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2b) Gecko/20020929 Phoenix/0.2
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2b) Gecko/20020929 Phoenix/0.2

There's so much empty space to the right of the menu items; I'd like to be able
to stick a few buttons there.

(I'd like to be able to customize the menu item positions individually, but for
now, you could treat them as you treat the personal toolbar items: as a group.)

Reproducible: Always

Steps to Reproduce:
1. Open Customize Toolbars dialog
2. Try to place an item to the right of the menu items.


Actual Results:  
Can't put anything next to the menubar items.

Expected Results:  
Treat the menu like the personal toolbar bookmarks; be able to place toolbar
items on either side.

Comment 1

[Asa Dotzler [:asa]]

not part of the plan. 

Comment 2

[Asa Dotzler [:asa]]

verified.

Comment 3

[David Tenser [:djst]]

Why not? It's very good and I always use it in IE. 

Comment 4

[Darren Salt]

Attachment: Creates an extra toolbar to the right of the menu bar.

In which case you'll like this patch...

It's done this way to remove any possibility of moving the menus themselves
(yes,
I've tried that, and it's... interesting). A side-effect is the addition of
support for arbitrary horizontal stacking of toolbars, which might one day be
useful :-)

Comment 5

[djk]

Darren Salt:
Thank you, thank you, thank you!
I'm using your patch as I type; it's great!

One thing, though.  Why did you not hide the menu when going into fullscreen mode?
I changed it back in my local copy...


Phoenix Maintainers:
I know this particular item isn't part of the Phoenix plan, but there is a patch
that appears to work; could it go in?

Comment 6

[David Tenser [:djst]]

Please check this in, it's great! I want to be able to have the menu, the
toolbar and the address field on the same row. It's the way I'm used to have it
in IE, so why should Phoenix not let me do it? Very tempted to reopen... 

Comment 7

[Darren Salt]

Attachment: Creates an extra toolbar to the right of the menu bar.

Bug fixes, basically, but this is the full patch.

* No longer leaves the menu bar visible in full-screen mode.
* No longer causes Phoenix to hang on closing the toolbars customisation window

  if there are empty toolbars.

Comment 8

[Asa Dotzler [:asa]]

Darin, this sounds like a fine mozdev project. I encourage you to get set up
over there and use their infrastructure rather than ours for the development of
this extension. 

This issue is closed. The Module Owner has made a decision and this request will
not be implemented in Phoenix.

(preemptive warning for anyone coming from mozillaZine where it was suggested
that enough people reopening or voting for this bug might help it get
incorporated into Phoenix:  Don't. The Module Owner has said this won't happen.
Reopening this feature request will be considered abuse of our system which
could lead to your Bugzilla account being disabled. This isn't a democracy and
the Module Owner has spoken.) 

Comment 9

[David Tenser [:djst]]

It would be a lot easier for us to understand why this fine patch will not get
checked in if The Module Owner could give us another reason than "not part of
the plan".

Comment 10

[David Hyatt]

(1) Performance - customizing of menus would be very slow and would dramatically
impact New Window time, since unlike toolbar widgets they have a lot of sub-content.

(2) Mac - XUL is still a cross-platform language, and the <menubar> needs to be
kept as a separate entity.  If we moved <menu>s into the palette and just built
up the <menubar> like a <toolbar>, then we violate that rule.

Comment 11

[djk]

Since I don't fully understand the attached patch or XUL, I may be wrong, but:
I think the patch only creates a new toolbar to the right of the menubar.  I
don't believe that it enables menu editing or moving the menu itself.

If I understand David's critisism of this request, those are the two things
stopping this bug.

I'm sorry for including those two items in my initial bug comment.
All I really want is what the patch implements: another toolbar to the right of
the menu.

If I'm wrong about this, I'll just shut up and keep on patching my own builds. :-}

Comment 12

[David Hyatt]

Ah, I misunderstood what this bug is doing.  I thought this was about
customizing the actual menus.

This is an interesting idea and works rather well, since you don't violate the
integrity of the <menubar>. 

Does the toolbar show up in the Toolbars->Show/Hide menu.  I don't think it
should if it does.  This should be a sort of "invisible" toolbar drop target.

Comment 13

[djk]

> Does the toolbar show up in the Toolbars->Show/Hide menu.  I don't think it
> should if it does.  This should be a sort of "invisible" toolbar drop target.

Yes, the toolbar shows up in Show/Hide.

I can see what you're saying about it being 'invisible', but turning that
toolbar off allows a (temporary) gain of vertical browser space if you have
icons in that toolbar.

Comment 14

[David Hyatt]

Also, getElementsByTagName does a complete crawl of the toolbox's subtree (which
includes the <menubar>), so that is extremely slow.  That should be avoided.

Comment 15

[Asa Dotzler [:asa]]

*** Bug 172516 has been marked as a duplicate of this bug. ***

Comment 16

[David Tenser [:djst]]

I was very glad to wake up today and read that the bug has been reopened and
even targeted!

A toolbar on the right is good, but would it be possible to place the whole menu
inside a toolbar instead, to allow moving of the actual menu? (I'm not talking
about individually moving the menu element, but the menu as a whole.) If not,
I'm fine with the toolbar on the right solution. But I don't think if should be
"toggable" from the View menu. The menu should always be visible.

Comment 17

[Kim]

Bug 172516 (The duplicate bug) addressed the issue of putting items to the right
and left of the menubar. It's been marked as a duplicate, so allowing the
menubar as a whole to be moved about seems to be how this is being addressed. It
might be interesting to allow users to hide the menubar if they wish, which
would make pheonix very unique as far as browsers go. Of course whether this is
right or not could be debated until doomsday, and either way would be acceptable.

I'm very glad it's being addressed. This bug is about the only problem I've had
with pheonix so far :) I love this little browser...

Comment 18

[Darren Salt]

It's possible to wrap the menu bar in a <toolbaritem>, which will make it
moveable. However, as noted, whichever toolbar contains it will have to be
omitted from the View > Toolbars submenu; unhiding that toolbar will be, er,
Somewhat Interesting.

I don't plan to revise my patch to do this; I'd rather have every <toolbar>
wrapped in an <hbox> (this patch wraps the menu bar and the additional toolbar
in an <hbox>, as it happens) and to allow rearrangement of the toolbars
themselves. That would allow you to create a new toolbar and to put it to the
left of the menu bar if that's what you want; and if it is, I suggest that you
(D.T.) file a separate enhancement bug.

WRT getElementsByTagName, a search-depth-limited or recurse-if-(not-)these
version of it would be nice (hmm, worth filing a separate bug for this?), but it
should be fairly easy to write something which will address the problem for both
this bug and bug 172517.

Comment 19

[Darren Salt]

Attachment: Function to (quickly) find UI elements of a given type; depth-limited

This works, although I'm not sure where it really belongs.

To use it (as it is now), you'll need to append it to the patched version of
customizeToolbar.js then replace
  gToolbox.getElementsByTagName ("toolbar"
with
  getNearbyElementsByTagName (gToolbox, "toolbar"

Comment 20

[David Hyatt]

The right structure (if you want to pave the way for movable toolbars) is to 
probably have a new element called a <toolboxrow>, and a <toolboxrow> would 
just be a horizontal box that contained any number of <toolbar>s.

Then the <menubar> and the <toolbar> that you've made can be wrapped in 
<toolboxrow>s, as can new toolbars when they are created via the dialog.

Also add a capability to make a toolbar be excluded from the View/Toolbars 
submenu, e.g., via an attribute on the toolbar.  <toolbar 
canshowhide="false"/>.

Do all that and use Darren's supplied function and I think this will be ready.

So to summarize:
(1) Make <toolbar>s be wrapped in <toolboxrow>s.  Make the <menubar> and your 
<toolbar> share a <toolboxrow>.
(2) Don't use getElementsByTagName.  Use the new function.
(3) Add support for a canshowhide attribute on toolbars to exclude them from 
the View/Toolbars menu.

Comment 21

[Walter Dnes]

  There's another way of doing this, *WITHOUT ADDING MENU-BAR TO THE RIGHT*. 
Note that the "Bookmarks" item is duplicated in the main and customization
menus.  How difficult would it be to...
  1) Copy "File", "Edit", "View", etc buttons to the "Custom Toolbar" menu
  2) and allow to hide the "Main menu"

  People could have their custom all-in-one menu+navbar and the sacred main menu
would remain untouched.

Comment 22

[David Hyatt]

Fixed.  No doubt people are going to keep clamoring for more.  Feel free to file
separate bugs.

Comment 23

[Brant Gurganus]

VERIFIED Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030714
Mozilla Firebird/0.6

Comment 24

[Simon Paquet [:sipaq]]

Taking QA Contact