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.

Why do we need resizable toolbars? Resizable in which direction?

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

I haven't tried it, but it looks like google bar already has something like this. See http://googlebar.mozdev.org/screenshots.html.

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.

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.

MPT: You're being deliberately obtuse. Reopening.

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.

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.

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.

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.

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.

jag, that bug is ancient and is visible in the sidebar (both horizontally and vertically) jag's demo verifies that there is indeed no problem that doesn't work for us.

> 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. However: 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.

*** This bug has been marked as a duplicate of 48926 ***

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.

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?

That would be a very confusing UI.

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.)

Verifying resolution of all bugs I've reported.