Open
Bug 15322
Opened 25 years ago
Updated 5 months ago
Ability to rearrange toolbars (by drag and drop)
Categories
(SeaMonkey :: UI Design, enhancement)
SeaMonkey
UI Design
Tracking
(Not tracked)
NEW
People
(Reporter: CodeMachine, Unassigned)
References
(Depends on 1 open bug, Blocks 2 open bugs, )
Details
(Whiteboard: [cst: probably never happening])
Attachments
(1 file, 6 obsolete files)
28.55 KB,
patch
|
Details | Diff | Splinter Review |
At the moment there's no way to reorder the toolbars vertically. It would be
nice to. I'm not sure how this should be done however, ie I'm of the opinion
that a skin's XUL and CSS should not be changed by this operation. For example,
does the current feature of hiding toolbars edit the XUL?
Once this is done, I'll put in a nice RFE to put multiple toolbars on the same
line.
Reporter | ||
Comment 1•25 years ago
|
||
At the moment, the bottom toolbar is in a different toolbar than the top ones.
This should be changed so that you can drag the bottom toolbar to the top if you
want.
This might require allowing things other than toolbars to appear in a toolbox.
This should be doable, simply don't allow them to be dragged/collapsed in the
same way (although maybe you MIGHT want to allow this for anything for some
applications using the Mozilla architecture, especially the ability to float
bits of content (when implemented for toolbars)).
Updated•25 years ago
|
Target Milestone: M14
Comment 2•25 years ago
|
||
m14
Updated•25 years ago
|
Assignee: trudelle → hyatt
Target Milestone: M14 → M18
Comment 3•25 years ago
|
||
reassigning to hyatt for m18
Reporter | ||
Comment 4•25 years ago
|
||
It would be nice to be able to move a toolbar a horizontal toolbar to be
vertical as well.
Basically a toolbar should be able to move to any border of its bounding box.
Updated•25 years ago
|
Status: NEW → ASSIGNED
Updated•25 years ago
|
Summary: Toolbar movement. → [feature] Toolbar movement.
Comment 5•25 years ago
|
||
No time left in this release, resolving as later, putting on helpwanted radar
Comment 6•25 years ago
|
||
reopening all latered bugs
Status: RESOLVED → REOPENED
Resolution: LATER → ---
Comment 7•25 years ago
|
||
Moving all latered bugs to M20 as ordered by project manager. Although these
bugs are now open, assigned and targetted, XPToolkit has no plans to
fix/implement them in the current release cycle, if ever.
Target Milestone: M18 → M20
Comment 8•25 years ago
|
||
Mass move of all M20 bugs to M30.
Comment 10•25 years ago
|
||
Please don't include the menubar like IE does.
Comment 11•25 years ago
|
||
Mass-moving all M20-M30 XPToolkit bugs to Future
Target Milestone: M30 → Future
Comment 12•24 years ago
|
||
*** Bug 47584 has been marked as a duplicate of this bug. ***
Comment 13•24 years ago
|
||
I propose putting this on the radar for mozilla1.0.1. There are other bugs
dependent on this, and it's been open for about 1.5 years now. What do you think?
Updated•24 years ago
|
Keywords: mozilla1.0
Comment 14•23 years ago
|
||
I put together a patch to enable vertical reordering of toolbars (within a
toolbox) by dragging the grippy handles. This is my first patch so I'd
appreciate any advice!! Diff was made using Gerv's patchmaker utility based off
win2k build 2001100610. I had to hack the patchmaker script to get it to work
on my system, so hopefully it works.
The patch borrows a lot from the outliner column reordering. It uses the
ordinal attribute to control display order so it doesn't mess with the content
model.
There are several issues with the patch as-is, off the top of my head:
- XUL authors can't specify whether toolbars can or can't be reordered; it
currently applies to all toolbars. Probably should add an "enableToolbarDrag"
attribute or something similar on the <toolbox> to specify.
- Same as above for persisting the order; right now it's always persisted.
- Doesn't distinguish between toolbars and menubars, both can be dragged
(good/bad is a matter of opinion).
- Dragging is confined to the <toolbox>. Anything more is a much larger scope.
- User feedback as to where the dragging toolbar will be inserted needs work.
It's specified on a per-skin basis. The current patch adds a black line for
feedback to classic and modern skins, but it sucks. Needs polish.
- Weird things may happen when adding new toolbars via overlays after reordering
existing toolbars. Same to a lesser extent with turning on toolbars that were
turned off or collapsed during reordering.
- Others, I'm sure. Needs to be put through its paces, esp. with overlays.
Comment 15•23 years ago
|
||
Updated•23 years ago
|
Status: REOPENED → ASSIGNED
Target Milestone: Future → mozilla0.9.6
Comment 16•23 years ago
|
||
Fantastic, Jason! I'll look at this tomorrow (Monday).
Assignee | ||
Comment 17•23 years ago
|
||
Jason: cool :-) I think, however, that there may be a problem with your patch,
possibly due to a bug in Patch Maker.
Could you please download and drop in the latest version, Patch Maker 0.4, and
re-create the patch (pmd)? Then, remember to attach the file that ends in .diff
(and not .chromediff.)
Gerv
Comment 18•23 years ago
|
||
There are a few lines that show up as changed when you didn't actually change
those lines. Either you inserted extraneous spaces that should be removed, or
patch maker is doing it. Not sure which.
Comment 19•23 years ago
|
||
Gerv and Dave-- I see what you mean about the patch. I'll try using the new
version of Patchmaker when I get home tonight. The patch I attached was the
.diff not the .chromediff, but looking at the two they're exactly the same to
the character. So something with the chrome->cvs diff conversion isn't
happening right. I'm thinking it might have something to do with perl treating
the backslashes in the chromelist as escape characters; I'll let you know what I
find out.
I think that the deal with unchanged lines showing up as changed has to do with
the "feature" of my text editor where it strips trailing whitespace off each
line when saved. Handy when writing HTML, but I obviously need to turn it off
or use another editor for Mozilla hacking. ;-)
I'll attach a revised patch hopefully tonight.
Comment 20•23 years ago
|
||
Actually don't. Stripping off trailing whitespace is a good thing. :)
Comment 21•23 years ago
|
||
Okay, I think I got it figured out. Gerv, it was an issue with the
chromelist.txt using backslashes in the chrome paths, which perl was treating as
escape characters. Changing them all to foreslashes, as in the unix version,
made it play nice. (I'm running Win2K; it doesn't have a problem with
foreslashes for paths, but other Win32 versions may.)
My next version of the patch, besides hopefully being a valid patch ;-), has
some changes for performance and neatness, as well as an attempt to fix the
problems with un-hiding toolbars or overlaying new toolbars. It sets the
ordinals to negative integer values when reordering, so theoretically a newly
added toolbar should display at the bottom since its initial value should be 1
(per the spec). However, this doesn't appear to be working (new toolbars show
at the top.) Dave, is this perhaps a bug with the ordinal implementation, or am
I interpreting it wrong?
Comment 22•23 years ago
|
||
Comment 23•23 years ago
|
||
Comment 24•23 years ago
|
||
Above patch (version 3) eliminates the stupid black line; it just goes ahead and
moves the toolbar. This is much simpler and brings it much closer to the
Communicator 4.x behavior.
Comment 25•23 years ago
|
||
Does the scope of this bug cover being able to move toolbars to bottom of the
window, where the Components Bar and Status Bar are?
Comment 26•23 years ago
|
||
Unfortunately enabling toolbars to be moved to the bottom of the window would
require a rethink of the whole toolbox/toolbar system. While I'm not opposed to
that, I think we should make small steps to 4xp first, and then consider larger
changes post-1.0. Maybe you should file another bug for allowing toolbars be
moved outside their toolbox.
Comment 27•23 years ago
|
||
Adding a toggle to move the toolbar to the bottom of the window would require
approximately 8 seconds of work.
Comment 28•23 years ago
|
||
It took asa 8 seconds. I can do it in 4.
Comment 29•23 years ago
|
||
Oh, my bad, I see you already have a patch with box ordinal so you're obviously
aware of it (I thought you were plairoesque)...so why would it be so difficult?
Asa did it in his userchrome with one line. Maybe I'm missing what's being
asked for?
Comment 30•23 years ago
|
||
I thought that Tim was asking for single toolbars (e.g. the personal toolbar
ONLY) to be moved to the bottom of the window; I think what Asa did was to move
the whole *toolbox* to the bottom. If I'm mistaken please let me know how it
was done so I can incorporate it into my patch. Thanks.
Plairoesque... heh. ;-)
Comment 31•23 years ago
|
||
*** Bug 104324 has been marked as a duplicate of this bug. ***
Comment 32•23 years ago
|
||
Comment 33•23 years ago
|
||
Version 4 of the patch is finally what I'd call review-ready. I'll address each
of the issues I brought up on Oct.6:
- XUL authors can now specify the attribute: preventToolbarDrag="true" on the
<toolbox/> element to prevent the user from rearranging its bars. This seemed
much better than having to specifically allow dragging on each and every toolbox.
- I left it so that the order is always persisted after a drag. It seemed to me
that it's sort of an "all-or-nothing" on persistence, and would be a pain for
XUL authors to have to add persist="ordinal" to all their toolbars.
- Toolbars and Menubars can both be dragged; if you don't want to change the
position of your menubar, then ... don't.
- Dragging is still confined to the toolbox. I still think the toolbox/toolbar
scheme will have to be rethought in order to allow anything more.
- Toolbars are rearranged while dragging, so no user feedback issues.
- I changed the default -moz-box-ordinal-group for toolbars to -1 in xul.css (if
there's a better place for this let me know.) so that newly added toolbars will
display at the bottom. This doesn't apply for menubars so they'll display at the
top.
- There still may be bugs but I didn't find any when adding 3 overlayed toolbars
to the default 4 in navigator.
So I guess this is ready for review when y'all get a chance.
Updated•23 years ago
|
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Comment 34•23 years ago
|
||
Can you get me a patch that is current with the tip? I'll take a look at that
and supply comments.
Comment 35•23 years ago
|
||
Thanks Dave- I'll be out of town until Monday; I'll attach a current patch when
I get back next week.
I also need to have it tested on Macintosh, since I remembered the <menubar/> is
kept on the top of the screen on the Mac and I don't know how that would behave
with box-ordinal.
Comment 36•23 years ago
|
||
I found a few minutes to update the patch to the tip. This is exactly the same
code as before; there were no merge problems. I look forward to your input.
Attachment #52415 -
Attachment is obsolete: true
Attachment #52658 -
Attachment is obsolete: true
Attachment #52981 -
Attachment is obsolete: true
Attachment #53453 -
Attachment is obsolete: true
Updated•23 years ago
|
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Comment 37•23 years ago
|
||
I tested this in Win2k with build 2001120303 (I get lots of javascript errors,
not related to this bug - I believe)
I found one or two little problems with the operation of this patch though.
- There is no visual feedback. How about changing the mouse cursor when dragging?
- When I move the cursor outside of the window, it stops dragging. Was this
intentionally done? (Couldn't find the spot in the code which handles this) With
no visual feedback it's hard to know if I'm still dragging or not.
- In the message compose dialog, you have to drag some of the toolbars, what
seems like, a large distance before they'll move.
Works fine with the translate bar (you can't move the bar up) and the site
navigation bar on autohide. It also appears to work in all other windows which
have toolbars at the top.
When the toolbars were collapsed, I couldn't seem to re-arrange them. That's
probably a good thing :)
As for the code, it looks good, but I'm not one to make suggestions on that.
The patch seems solid though.
Comment 38•23 years ago
|
||
Thanks for your comments, Neil. Any JS errors that have to do with this patch
would show toolbar.xml as their source -- any other source is most likely unrelated.
> - There is no visual feedback. How about changing the mouse cursor when
> dragging?
I agree that some sort of user feedback would help. What's the etiquette for
changing the cursor; can I do that directly with a .style.cursor in the JS, or
do I need to set an attribute somewhere and let the skin CSS determine how the
feedback is displayed?
> - When I move the cursor outside of the window, it stops dragging. Was this
> intentionally done? (Couldn't find the spot in the code which handles this)
> With no visual feedback it's hard to know if I'm still dragging or not.
This was intentionally done as a workaround for not being able to detect mouse
events outside the window. I couldn't detect when the user dragged outside the
window and let up the mouse button, so when the mouse came back into the window
the toolbar would still be dragging and you'd have to click in the toolbox to
cancel it. I agree this is a less-than-elegant workaround, so if anyone has a
better idea I'm all ears.
Actually dragging is canceled whenever the cursor enters a region of the window
that is not within the originating <toolbox/>. The code to detect this is in
the toolbox.dragMouseMoved method. BTW, this is the exact same behavior as in
Communicator 4.x.
Implementing visual feedback (cursor, etc.) will help out with this, so the user
will see when his drag has been canceled.
> - In the message compose dialog, you have to drag some of the toolbars, what
> seems like, a large distance before they'll move.
The toolbar will snap to the closer side of whichever toolbar the mouse is
currently over. So the mouse has to move past halfway down the height of the
toolbar to make the toolbar snap to the lower position. This can make it seem
very resistant over huuuuuge toolbars like in message compose, but it's the only
way I can think of that makes sense. Suggestions welcome as always.
=======
So, to summarize:
1) Is it polite to set .style.cursor="move" directly in the JS?
2) Is there a way to detect mouseup events outside the window boundaries? I
found window.enableExternalCapture() in lxr but it appears to not be implemented.
Comment 39•23 years ago
|
||
> This can make it seem very resistant over huuuuuge toolbars like in message
> compose, but it's the only way I can think of that makes sense. Suggestions
> welcome as always.
Well, an alternate way would be to grab the X, Y of the mouse, then when it
moves, you figure out if it has been moved up or down. Then you check to see if
it has moved outside a tolerance. That way, it wouldn't matter how big the
toolbar was. Of course you might run into problems if the mouse hits the top of
the screen and stops.
eg, the tolerance is 5px. So they click, and move the mouse up 5px. The
toolbar moves up one slot. They move 10px, and it moves up 2 slots.
It might also run into problems later on if you allow multiple toolbars on one
line, or docking on the side and stuff.
Anyways, it's just a suggestion. I don't have a preference either way.
Comment 40•23 years ago
|
||
Is this going to have to be retooled when we get to 48926, or is it extensible?
Comment 41•23 years ago
|
||
Dean-- this is code based on the current toolbar/toolbox relationship. The
current design is very basic and inflexible, therefore so is the code to
manipulate it. Bug 48926 would basically be a (well-needed) complete rebuild of
the toolbar widgets, and so I doubt the code in this patch would work in that
new system. But that rebuild seems a long way off (futured), and this is a
relatively simple patch that could give us some nice added functionality in the
short-term.
Speaking of 48926, I really don't think this bug blocks that one. Anyone agree?
Comment 42•23 years ago
|
||
*** Bug 114830 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Comment 43•23 years ago
|
||
I just noticed attachment 65067 [details], a complete spec for the toolbar system
redesign, submitted by MPT in bug 49543. It's quite apparent that the work I've
done for this bug will not fit in that new system whatsoever, so I hereby
withdraw my patch in favor of moving ahead toward the toolbar rewrite.
Thanks everyone for your input. It's been a great learning experience and I
hope to be able to contribute to the rewrite in some way.
Updated•23 years ago
|
Target Milestone: mozilla0.9.9 → mozilla1.2
Comment 44•23 years ago
|
||
adding self to cc list
Comment 45•22 years ago
|
||
Do consider allowing toolbars (and the menu) to be arranged horizontally. My ie
config, when I use it has a compact, three row setup with the
<- -> Location: [ ]
Google bar [ ] File ....... Help
Personal Toolbar Links
It would be great for Mozilla users to have this flexibility, too.
Comment 46•22 years ago
|
||
*** Bug 156269 has been marked as a duplicate of this bug. ***
Comment 47•22 years ago
|
||
Jason:
> I just noticed attachment 65067 [details], a complete spec for the toolbar
> system redesign, submitted by MPT in bug 49543. It's quite
> apparent that the work I've done for this bug will not fit in
> that new system whatsoever, so I hereby withdraw my patch
> in favor of moving ahead toward the toolbar rewrite.
According to bug 22056 comment 100, Marlon stopped working on MPT's spec in
February. As far as I can tell by sorting a mess of related bugs, nobody else
has picked it up. So I wouldn't count on the spec being implemented any time
soon at all. Incidentally, MPT's spec SHOULDN'T have been attached to bug
49543. It has some tangential relationship (as future nanotechnology does to
current medicine), but no actual direct bearing on the resolution of the bug.
Further, if you look at recent discussion in bug 49543, one suggestion is to
reverse the dependency between that bug and bug 48926. However, THIS bug is
marked as blocking bug 48926. So, if no more work is done on this bug because
it's waiting for MPT's spec, which Marlon has stopped working on, which blocks
bug 48926, which would also then block bug 49543 - that would make at least 3
bugs (and there are more indirectly), plus MPT's spec itself, which have had
development halted.
Is there any chance of persuading you to continue with your patch? Even if, a
long way down the road it becomes obsolete, it would go a long way in the
immediate future towards addressing a lot of problems.
Comment 49•22 years ago
|
||
What we need is a *real* implementation. My patch, while perhaps better than
nothing, is a half-assed one: it only allows vertical rearrangement, gives
insufficient visual feedback, and resorts to some hacks which might affect
profile compatibility if it were replaced in the future with a real
implementation (due to storing ordinal values in localstore.rdf).
If someone else wants to continue development of my patch that's fine, but I'm
afraid I won't be the one doing it because (1) I don't think it's the right
thing for the product at this point, (2) I'm not skilled enough, and (3) I just
don't have the time right now.
I'd rather see a knowledgeable developer attack this and/or the dependencies.
I'm willing to wait for it to be done right.
(On a side note, I've noticed some great UI customizability in Venkman
recently; perhaps the code for those floating views can be used as a starting
place for arrangeable toolbars?)
Comment 50•22 years ago
|
||
--> default owner
Assignee: hyatt → jaggernaut
Status: ASSIGNED → NEW
QA Contact: claudius → jrgm
Target Milestone: mozilla1.2alpha → ---
Comment 51•22 years ago
|
||
*** Bug 175482 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
Summary: [feature] Toolbar movement. → Ability to rearrange toolbars (by drag and drop)
Comment 52•21 years ago
|
||
Is there any active work done on this bug/enhancement? It has been many years
since it is opened and it is stil new.
I've installed quite a few plugin from mozdev and they occupies several rows,
even though most of them took less than half of the row. It would be nice to
arrange them like in IE (I've never been a IE fan). Otherwise things are too
clumsy.
Comment 53•20 years ago
|
||
@Hao Huang : Given the long wait with no reply I think you can safly asume that
the answer to your question is a "no"
This bug seems to have gone stale.
It might also be a thing more suited for Firefox , should we change the
"product" to make it reflect this ?
Comment 54•20 years ago
|
||
> It might also be a thing more suited for Firefox , should we change
> the "product" to make it reflect this ?
No. If it's something desired for Firefox then a new bug should be opened.
This bug is targetted specifically against Seamonkey.
Comment 55•20 years ago
|
||
Considering that (a) the Firefox/Thunderbird XUL has this feature and it
works well, and (b) the Seamonkey frontend is stable and in maintenance
mode, I strongly suspect this bug is really a WONTFIX.
Comment 56•20 years ago
|
||
(In reply to comment #55)
> Considering that (a) the Firefox/Thunderbird XUL has this feature and it
> works well, and (b) the Seamonkey frontend is stable and in maintenance
> mode, I strongly suspect this bug is really a WONTFIX.
Exactly HOW does one do this in/with XUL?
Comment 57•19 years ago
|
||
*** Bug 303251 has been marked as a duplicate of this bug. ***
Assignee: jag → cst
Component: XP Toolkit/Widgets → XP Apps: GUI Features
Keywords: helpwanted
Priority: P3 → P2
Product: Core → Mozilla Application Suite
Target Milestone: --- → Future
Attachment #58812 -
Attachment is obsolete: true
You can reorder toolbars vertically, and you can have multiple toolbars on a
row. Drag by the grippy. Drop over another toolbar (see item 3 below).
-1) This patch uses eval().
0) I have a lot of if(0)'ed out dumps. It still spews a little bit of info in
the constructor / destructor, but you can get a lot more by putting the dumps
back in.
1) Requiring flex on the <toolbar> is probably bad. I should set it myself in
the toolbox constructor. That should be safe, because right now nobody should
have anything in which toolbars already flex.
2) Existing ondrag* handlers for toolbars can cause problems, which is why I
modified the personal toolbar folder.
3) Drop over the left or right 15% of the width of a toolbar to drop onto the
same row. If you drop over the middle 70%, it will go above or below the
toolbar you dropped on. I picked those constants arbitrarily. If I could do
stretched images in XUL, some visible indicator would be nice
4) MSIE moves as you drag. MSIE also makes it VERY hard to get the arrangement
you want, so I move only ondrop, but with much better usability.
5) XBL doesn't like DOM nodes moving around. Fortunately, the URL bar was the
only problematic thing, and even that has a fairly easy workaround. I have
seen it occasionally fail to find the url bar in the constructor though, and
I'm not entirely sure it works 100% of the time.
6) The ">>" at the end of the overflowed menu should really stay next to the
splitter no matter how narrow you make the menubar (well, until it's narrower
than the ">>" itself). For some reason, it won't move more than one menu left
of where it starts. I have no idea why this is.
7) Toolbar overflow should be hidden or it will be visible in adjacent toolbars
(just the leftmost overflowing item will, the rest won't). I couldn't get it
to hide from communicator.css so I used inline CSS.
8) I don't do nice collapsing of toolbar contents. Fundamentally it should be
possible. I'm not sure if it's worthwhile though... for SeaMonkey 1.1 I'd hope
we have toolkit's customizable toolbars, which would let you have everything on
one line and it would look good (whereas automated collapsing would just chop
off the rightmost toolbar buttons). Flex elements also create headaches -
there's a long comment in the patch about this.
9) The menubar overflow ">>" button isn't as tall as the personal toolbar
folder's ">>" button. Oops.
10) The patch would be quite a bit shorter without the dumps.
Target Milestone: Future → ---
Attachment #196963 -
Flags: review?(jag)
Blocks: sm1.1
(In reply to comment #58)
> 0) I have a lot of if(0)'ed out dumps. It still spews a little bit of info in
> the constructor / destructor, but you can get a lot more by putting the dumps
> back in.
I removed the dumps.
> 1) Requiring flex on the <toolbar> is probably bad. I should set it myself in
> the toolbox constructor. That should be safe, because right now nobody should
> have anything in which toolbars already flex.
Fixed - I set it myself now in the constructor.
> 5) XBL doesn't like DOM nodes moving around. Fortunately, the URL bar was the
> only problematic thing, and even that has a fairly easy workaround. I have
> seen it occasionally fail to find the url bar in the constructor though, and
> I'm not entirely sure it works 100% of the time.
It seems to work properly now, and I changed the code a bit to work better for mailnews / things with no URL bar. Note that it still throws if the thing with the toolbar doesn't include nsDragAndDrop.js.
> 10) The patch would be quite a bit shorter without the dumps.
That's basically what I'm attaching.
Attachment #196963 -
Attachment is obsolete: true
Attachment #202850 -
Flags: review?(jag)
Attachment #196963 -
Flags: review?(jag)
see also bug 172818
Whiteboard: [cst: probably never happening]
Comment 61•18 years ago
|
||
Comment on attachment 202850 [details] [diff] [review]
patch v2
This patch is pretty bitrotted, "now" that bug 282188 is fixed...
> [cst: probably never happening]
Why?
(In reply to comment #61)
> (From update of attachment 202850 [details] [diff] [review] [edit])
> This patch is pretty bitrotted, "now" that bug 282188 is fixed...
>
> > [cst: probably never happening]
>
> Why?
>
I'm not going to write this just for 1.1a, and then do toolkit customization for 1.5, and I am under the impression that toolkit toolbars are definitely not happening on 1.1 so I could just take advantage of their customization support now for 1.1. I don't see much reason to have both drag-drop and toolkit customization.
-> somebody else
Assignee: cst → nobody
QA Contact: jrgmorrison → guifeatures
Updated•17 years ago
|
Priority: P2 → --
Comment 64•14 years ago
|
||
At the moment except for tabs most items are customizable. With the option to switch to tabs on tab the remaining problem is solved. This bug should be closed.
Comment 65•14 years ago
|
||
(In reply to comment #64)
> At the moment except for tabs most items are customizable. With the option to
> switch to tabs on tab the remaining problem is solved. This bug should be
> closed.
I'm now running the current Firefox 4 nightly and I cannot move File menu anywhere, all other toolbars are also unmovable because there's no handle for them, you just cannot pick them up to drag them.
So, I dare say this bug's far from being resolved.
Comment 66•14 years ago
|
||
Guys:
1. This is a SeaMonkey bug not a Firefox bug.
2. This bug is about rearranging toolbars not the buttons in the toolbars.
3. Neil Deakin is currently working on dockable toolbars, so stay tuned.
Comment 67•14 years ago
|
||
The firefox bug for this is bug 172818.
Updated•13 years ago
|
Attachment #202850 -
Flags: review?(jag-mozilla)
You need to log in
before you can comment on or make changes to this bug.
Description
•