Make menu position customizable.

RESOLVED INVALID

Status

()

--
enhancement
RESOLVED INVALID
17 years ago
6 years ago

People

(Reporter: david, Unassigned)

Tracking

Trunk
Future
Points:
---
Bug Flags:
blocking-aviary1.0 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: asa:ui)

Attachments

(4 obsolete attachments)

(Reporter)

Description

17 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3a) Gecko/20021112 Phoenix/0.4
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3a) Gecko/20021112 Phoenix/0.4

This is sort of building on the idea of bug 177343.

I'd like to suggest the ability to move the menu to any toolbar, with 2 conditions:
1) The menu may not be placed on the Customize Toolbar palette (it must be on a
toolbar somewhere).
2) Whichever toolbar the menu is moved to, may not be hidden by View->Toolbars

Reproducible: Always

Steps to Reproduce:

Comment 1

17 years ago
How does this bug differ in any substantive way from bug 177343? As I understand
it, this bug has the additional request of being able to move the menu element
to any toolbar and not just along the menubar. If this is the case then this bug
will have to be marked as a dupe of bug 177343... one can always add a comment
to an existing RFE provided that the comment has some bearing or relationship to
the original RFE, as would certainly be the case here; that is in fact how
Phoenix ended up having the ability to move custom elements onto the menubar in
the first place.
> How does this bug differ in any substantive way from bug 177343?

Bug 177343 is a bug report about the DND indicator still being used when
dragging the menu. 

This bug is a request to make the menu movable again. That feature was removed
for a reason, so this will most probably be WONTFIX'ed as soon as a developer
reads it.
OS: Windows 98 → All
(Reporter)

Comment 3

17 years ago
First, the reason I didn't just add a comment to bug 177343 is that this is a
new feture request.  Bug 177343 is tweaking/correcting the behavior of existing
functionality.


What was the reason for making the menu immobile?

I feel that the conditions that I listed above remove the major problem of menu
movement: (accidently) hiding the menu, with no easy/obvious way to get it back.

But I guess it's up to the developers. :-}

Comment 4

17 years ago
I did not know that this feature had been removed (or why, needless to say).
Given that, I'm going to mark it as WONTFIX [a little reluctantly].
Status: UNCONFIRMED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 5

17 years ago
Mr. James,

I believe that the movable menu was an unintended side-effect of making the menu
toolbar a target for customization.  I'm not too sure why this feature was
removed.  That's why I opened this bug; to ask for a proper implementation of a
movable menu.

In comment 3, I listed why I think the menu was made immobile.  Perhaps I'm
wrong, and the developers had other reasons.  I'd like to know the reasons.  As
long as there is some rational reason why this bug is WONTFIX, I can live with it.

I ranted in the MozillaZine forum about WONTFIX:
http://www.mozillazine.org/forums/viewtopic.php?p=5558#5558

Comment 6

17 years ago
I based my WONTFIX on the fact that the developers had apparently done something
intentionally as indicated by David Tenser in comment #2. Unfortunately neither
he nor I actually know what that reason is. So I'll reopen it and see what comes
of it.

-->Reopening
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---

Comment 7

17 years ago
-->Confirming as New for developer review
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

16 years ago
Whiteboard: asa:ui
(Reporter)

Comment 8

16 years ago
Created attachment 115636 [details] [diff] [review]
I don't know xul, but I can hack on it...

This implements the ability to move the menu items as a group.

You may not drop the menu onto the palette; it must be a toolbar drop target.

You may not hide the toolbar that the menu is on.  The toolbar name shows up in
view->toolbars, but it is disabled.  If you move the menu to another toolbar,
the previous one becomes hidable, and the new one becomes unhidable.

I don't know css/xul well enough to make the menu items 'collapse' when
customizing them (like the bookmarks currently do).  I leave it up to someone
else to implement that (or if I get mucho more time to mess around with it).
(Reporter)

Updated

16 years ago
Attachment #115636 - Flags: review?(hyatt)
(Reporter)

Comment 9

16 years ago
BTW, cdn's Compact Menu (http://cdn.mozdev.org/compact) works with this patch, too.

Nice.
(Reporter)

Comment 10

16 years ago
Created attachment 119182 [details] [diff] [review]
don't explicitly hide menubar in fullscreen toggle

Turns out that the menu bar would disappear when going to fullscreen mode, even
if it was located on the nav-toolbar.

Took out the line that explicitly called the hide function for the menubar, as
the menubar is implicitly hidden when its toolbar is hidden.
Attachment #115636 - Attachment is obsolete: true
(Reporter)

Updated

16 years ago
Attachment #119182 - Flags: review?(hyatt)
(Reporter)

Updated

16 years ago
Attachment #115636 - Flags: review?(hyatt)

Comment 11

16 years ago
I haven't looked at the patch at all, but I have one general comment.  Please
don't put your initials in your comments, just put the comment.  We have cvs
blame to determine who did what.
Taking QA Contact
QA Contact: asa → bugzilla
(Reporter)

Comment 13

16 years ago
Dean,

I'm sorry about the initials; I use them when developing patches so that I can
find my changes quickly when editing files.  Maybe I should find a better method.

I don't really have the time right now to update the patches, but if I find some
time, I'll do so.  Otherwise someone else will have to do the cleanup before
checkin.

At any rate, I'll refrain from putting my initials in future patches.

> Took out the line that explicitly called the hide function for the menubar, as
> the menubar is implicitly hidden when its toolbar is hidden.

FWIW, I seem to remember that this one particular problem was fixed in the meantime.

David
(Reporter)

Comment 14

15 years ago
Created attachment 143319 [details] [diff] [review]
updated patch

This is the patch, updated to a 2004-03-03 build of Fx.

There are some issues:
1) The Bookmarks Toolbar Items disappear when you "restore default set" while
customizing.  This sounds similar to a recent (fixed) bug where the menu
disappeared after the same action.  This is not introduced by my patch; it
happens to the vanilla build as well.

2) The placement of the toolbars in the View->toolbars menu is weird.  I
suspect something happened to insertBefore and XUL elements.  No idea what's
going on here.

Aside from those things, the patch seems to work. :-)

David
Attachment #119182 - Attachment is obsolete: true
(Reporter)

Updated

15 years ago
Attachment #143319 - Flags: review?(hyatt)
You should be asking Ben for review here.

/be
Assignee: hyatt → bugs
(Reporter)

Updated

15 years ago
Attachment #143319 - Flags: review?(hyatt) → review?(bugs)
I'll get around to reviewing this after feature hell. -> 1.0b
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → Firefox1.0beta
Comment on attachment 119182 [details] [diff] [review]
don't explicitly hide menubar in fullscreen toggle

obsolete patch
Attachment #119182 - Flags: review?(hyatt)
Nominate for 1.0 if you can create a patch that has no issues. ;-) 
Target Milestone: Firefox1.0beta → After Firefox 1.0
(Reporter)

Comment 19

15 years ago
Created attachment 148959 [details] [diff] [review]
updated patch for 20040519 Fx

Here's a new patch updated to current trunk.

It has no issues (as far as I tested) beyond those of the current trunk. :-}

David
Attachment #143319 - Attachment is obsolete: true
(Reporter)

Updated

15 years ago
Attachment #143319 - Flags: review?(bugs)
(Reporter)

Updated

15 years ago
Attachment #148959 - Flags: review?(bugs)
(Reporter)

Updated

15 years ago
Flags: blocking1.0?
Flags: blocking1.0? → blocking1.0+
Target Milestone: After Firefox 1.0 → Firefox1.0
Assignee: bugs → sspitzer
Status: ASSIGNED → NEW

Comment 20

15 years ago
This has l10n impact and we don't have QA to test new features for 1.0.
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
QA Contact: bugzilla → toolbars

Comment 21

14 years ago
Is this bug still alive, or should I post a new one, as we're more than one year
after the latest comment, and I'm still not able to move the menu?
The bug also have target milestone 1.0 witch is too late.
Assignee: sspitzer → nobody
Priority: P3 → --
Hardware: PC → All
Target Milestone: Firefox1.0 → ---
Version: unspecified → Trunk
Attachment #148959 - Attachment is obsolete: true
Attachment #148959 - Flags: review?(bugs)
(Reporter)

Comment 22

13 years ago
(In reply to comment #21)
> Is this bug still alive, or should I post a new one, as we're more than one
> year
> after the latest comment, and I'm still not able to move the menu?
> The bug also have target milestone 1.0 witch is too late.

I haven't hacked on firefox in a while.  But as I recall, this patch ran rather nicely.  I can only imagine that the code has shifted quite a bit since I last applied the patch to my local build; it probably doesn't work anymore.

If a driver would give feedback about the possibility of this being accepted, I _may_ be able to scrape up enough time to update the patch.

David
There is no chance this can land for Firefox 2, but a very good chance that it could make Firefox 3 if you prepare the patch.
Useful enough, would take patch for sure if something were ready/stable.
Target Milestone: --- → Future
the bug was forgotten?
(Reporter)

Comment 26

9 years ago
It was, understandably, pushed aside as 1.0 was nearing completion.  It was ignored by everyone during the 2.0 cycle.  When 3.0 came around with the chance to include the patch, I had no more time to work on it.

So, yes, this bug was forgotten, and remembered with poor timing.

David

Comment 27

8 years ago
With 4.0 now released, this seems like the ideal time to revive this bug.  This issue applies to the menu bar and the new menu button.

Comment 28

8 years ago
I can't work on the patch, but I'll 'confirm' that this issue still exists...
No longer relevant given the removal of the menu by default in australis.
Status: NEW → RESOLVED
Last Resolved: 17 years ago6 years ago
Resolution: --- → INVALID

Comment 30

6 years ago
> No longer relevant given the removal of the menu by default in australis.

Does the new menu button support movement between toolbars?  If so, I'd call this bug FIXED.  If not, this bug still applies to the new menu button.
You need to log in before you can comment on or make changes to this bug.