16 years ago
15 years ago


(Reporter: Jason Bassford, Assigned: jag (Peter Annema))


(Blocks: 1 bug)


Firefox Tracking Flags

(Not tracked)



(1 attachment)



16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1b) Gecko/20020719
BuildID:    2002071911

With the other bugs that are synergistically encompassing MPT's toolbar
customizability spec, especially bug 48926, bug 49543, and bug 15322, we need to
be able to dynamically resize toolbars.

This is not something that needs to be done prior to the implementation of one
or the other of the above bugs, but it shouldn't be neglected.


16 years ago
Blocks: 157199


16 years ago
Target Milestone: --- → Future

Comment 1

16 years ago
Why do we need resizable toolbars? Resizable in which direction?

Comment 2

16 years ago
Horizontally.  There is little point is being able to combine toolbars unless
the individual components can be resized.  See bug 48926 comment 26.

Comment 3

16 years ago
I haven't tried it, but it looks like google bar already has something like
this.  See

Comment 4

16 years ago
Worksforme, build 2002072103. Mac OS 9.2.2.

To reproduce:
1.  Resize a window to be wider than it was.

What should happen:
*   The toolbars get wider too, all by themselves.

What actually happens:
*   The toolbars get wider too, all by themselves.
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME

Comment 5

16 years ago
That is soo not productive. Don't pretend to misunderstand. If you
want to WONTFIX it, do so, but WFM is not helpful.

IF you want to continue to pretend you don't know what this bug's
about, when bug 48926 is fixed, this bug is asking for a way to alter
the relative widths taken up by each side-by-side toolbar.

Comment 6

16 years ago
MPT: You're being deliberately obtuse.  Reopening.
Resolution: WORKSFORME → ---

Comment 7

16 years ago
I think that XUL already has the support for this.  Fixing bug 48926 would
(should) automatically integrate this.  Otherwise the sidebar (already
implemented) wouldn't work, etc.  I don't see how this bug is necessary.  It
really is WFM.

Comment 8

16 years ago
I asked the question in bug 48926 25 what would happen to the size of the two
toolbars when they were combined - if they would each automatically size to 50%
or if the could be resized manually "to taste".  I didn't get a direct answer,
but was told I should open a separate bug to address the issue - which is this one.

Are you saying that the fix for bug 48926 will include a "resize grippy"?  If
so, then perhaps you're right - but no code has yet been checked into that bug
so there's no way of confirming.  If that bug does end up being fixed in such a
way, and there's nobody who wants a single toolbar to be resized, then I'd be
happy to see this bug resolved as INVALID.  But, until then, I think this bug
should stay open.

Comment 9

16 years ago
This bug is either worksforme or a dupe of bug 48926. Toolbars, like all other
XUL boxes, can be made any size using splitters. Part of the implementation of
bug 48926 should include inserting a splitter between the two toolbars.

Comment 10

16 years ago
1. Currently toolbars cannot be resized, neither on their own nor with
horizontally adjacent toolbars using splitters.  So, it's not WORKSFORME.  The
functionality doesn't yet exist.  (There is no need for it yet, which is why
it's marked Future.)

2. Bug 48926 has not yet been implemented, so there's no way of confirming that
when it is there will be a splitter used.  It may be a logical assumption, and
it may very well be what will happen, but until a patch is reviewed and checked
in containing one, this can't be marked as a duplicate.  (If a patch is checked
in for bug 48926 that does *not* contain a splitter, even if it should, and each
of the toolbars take up 50% of the space automatically, then this bug will not
have been fixed.)  If bug 48926 is checked in with a splitter I would be more
than happy to, at that time, mark this bug as INVALID.

Comment 11

16 years ago
Created attachment 93301 [details]
demo of toolbars that can be resized using splitters

There seems to be a bug so the text on the buttons doesn't correctly get
cropped or clipped, but in essence these toolbars are resizable.

Comment 12

16 years ago
jag, that bug is ancient and is visible in the sidebar (both horizontally and

jag's demo verifies that there is indeed no problem that doesn't work for us.
Last Resolved: 16 years ago16 years ago
Resolution: --- → WORKSFORME

Comment 13

16 years ago
> jag's demo verifies that there is indeed no problem that doesn't work for us.

<sigh> This is tiring.  I have no doubt that demos could be made of any number
of features that aren't currently part of Mozilla.  But just because you can
demo something, doesn't mean that it's made its way into the core code and is
actually "working" in a downloadable build.  WONTFIX is the wrong resolution. 

I am reopening this bug so that I can mark it as a (partial) duplicate of bug
48926, now that its summary / scope has been explicitly changed to include
toolbar resizability.

Jag: Why don't you attach your code to bug 48926?  Currently, the only thing
there is a screenshot of IE.
Resolution: WORKSFORME → ---

Comment 14

16 years ago

*** This bug has been marked as a duplicate of 48926 ***
Last Resolved: 16 years ago16 years ago
Resolution: --- → DUPLICATE

Comment 15

16 years ago
Jason: I'm not quite sure I understand the point of this bug then.

In your first comment, you say: "we need to be able to dynamically resize toolbars."

That can be read in many ways. One way is to say that all toolbars need resizing
widgets so users can arbitrarly size them. I would WONTFIX such an RFE. Another
way to read it is to have support for a widget that can be placed between two
toolbars on the same row so that the relative widths of those two toolbars can
be changed, without changing the total width. Such a widget already exists, and
addresses "we need to be able to dynamically resize toolbars".

Basically what this bug is asking for then is that when fixing bug 48926 we make
sure that when two toolbars are placed horizontally next to each other, that we
always insert a splitter. That should be dealt with in bug 48926, I think, so
I'll agree to your DUPE resolution.

Comment 16

16 years ago
There's another bug with the sample, too, in that using <toolbar> puts a
collapse widget at the left edge of each toolbar.  We'd only want this once per row.
do we? do we not want this once per toolbar?

Comment 18

16 years ago
That would be a very confusing UI.

Comment 19

16 years ago
People, this bug is closed as a duplicate of bug 48926 - please take the
discussion there.  (This sample code should be attached to the other bug.)

Comment 20

15 years ago
Verifying resolution of all bugs I've reported.
You need to log in before you can comment on or make changes to this bug.