The changes I have made involve adding the Menu Sharing API (originally authored by UserLand Frontier) back into Mozilla code base. If you examine the build instructions for Mozilla, you will see that the Menu Sharing Toolkit 1.4 is part of the build. However, this toolkit, as far as I can tell, was never hooked into the Mozilla build process. I don't know if this has always been the case, but it is definitely not part of the build process at this point. Projects widget.mcp docshell.mcp editor.mcp viewer.mcp Source Files nsMacMessagePump.cpp nsMacMessagePump.h nsMenuBar.cpp nsMenuBar.h nsMenu.cpp Make Files NGLayoutBuildList.pm Added to :mozilla:lib:mac MenuSharing folder Added to :Metrowerks CodeWarrior:MacOS Support:Libraries:Runtime:Runtime PPC:MW_MSL.Carbon.Shlb from CodeWarrior Beta 6 build 4.1B4 I have Carbonized the Menu Sharing API client code and I added two new targets, for Carbon, to widget.mcp. In addition, I changed the names of the output files of the widget.mcp from widget.shlb and widgetDebug.shlb to widgetPPC.shlb and widgetPPCDebug.shlb. The output name changes for the widget.mcp is the reason why I had to make modifications to docshell.mcp, editor.mcp, viewer.mcp. The Carbon targets will build widgetCarb.shlb and widgetCarbDebug.shlb. I changed the make file NGLayoutBuildList.pm to build the MenuSharing.mcp project for both PPC and Carbon. I changed the widget.mcp project file so that it could build both PPC and Carbon. I have successfully built debug and non-debug versions of Mozilla with my changes incorporated. I have not tried building Carbon versions of Mozilla since hasn't completely been Carbonized yet. I had to add MW_MSL.Carbon.Shlb from CodeWarrior Beta 6 in order to build the Carbon shared library. The MW_MSL.Carbon.Shlb doesn't exist under CodeWarrior 5.3.

Confirmed

Todd: please say what format the attachment is in. I can't decode it, since the MIME type is application/octet-stream. You are correct, the MenuSharing stuff was never added to the build. > In addition, I changed the names of the output files of the widget.mcp from > widget.shlb and widgetDebug.shlb to widgetPPC.shlb and widgetPPCDebug.shlb. Why? Also, our carbon porting effort is ongoing, and I don't think we need to take additional carbon porting changes as part of the MenuSharing work. The menusharing code is just 2 files, if I recall (MenuSharing.c/.h), so I don't think we should make a new dir under mozilla/lib/mac for it. If we did, then the CVS module would have to be changed to pull this directory. In addition, I still have not had a response from you on the legal issues with adding the MenuSharing code to the mozilla tree. This ain't gonna happen for NS6 RTP, so Future. We might take this for Mozilla 0.9 if the various issues are resolved.

reassigning to pinkerton for review. Putting on the rtm radar since Todd very much wanted to get this into Netscape6. Simon, could you please super-review this after we have the module owner review?

Brodia provides a set of services to simply purchasing products over the Internet. Services include password management, product research, price comparison, merchant evaluation, automatic form filling, enhanced payment security, transaction record keeping, privacy protection, and a rewards program. Currently Brodia supports both the Windows and Macintosh platforms, however the Macintosh support is currently limited and lacks many of the features available on the Windows platform. Our next major product release, called Card 2.0, needed a means to communicate between the Card application and the browser. The Menu Sharing API provides the communication and control that we need by inserting a menu into the browser’s menu bar. The Menu Sharing API has been a part of Netscape’s browser for almost six years. The API works under Mac OS 8, 9, and X. I currently have a Menu Sharing server and a Menu Sharing client running under Mac OS X. In addition to Brodia, I know of at least two other programs that use the Menu Sharing API: UserLand Frontier and URL Manager Pro.

The first three attachments can be removed if some one has the power to do that. I have added two new attachments: one in Mac hqx format and the other in Windows zip format. This way you should be able to extract the files on either Mac or Windows.

really ->pinkerton, cc self

Added attachments of Menu Sharing sources and diffs with branch Netscape_20000922_BRANCH extractable on both Mac and Windows.

I'm really sorry, but we aren't going to be able to take this feature for N6.0. Please continue to work to get it into the trunk. rtm-

It is my understanding that I have everything I need to do in order for this code to be included in Mozilla. Unless I am informed otherwise I will assume that there is nothing else I need to do.

You need to pass code reviews by the module owner (pinkerton) and one of reviewers@mozilla.org (sfraser). Once you have that, you'll need to check the code into the mozilla trunk, and be watching the builds, ready to fix any problems it causes. The instructions for review and other checkin policies are referenced at the top of the mozilla.org tinderbox page, please read them, know them, live them. mozilla.org is self-serve; you can usually get someone to help you get your contribution in, but they are unlikely to integrate your code into the code base on your behalf.

Where is the best distribution for the MenuSharing code? Is it on the net, or on a CD somewhere? I'm sure we're not allowed to check it into mozilla. We also need to make this work w/out the Carbonized MSL from Pro6, which we do not use.

The MenuSharing API is part of our build environment, and has been forever. The version we tell folks to install is the lastest (despite being old).

Sholdn't bug #13184 be marked as a duplicate of this one (or the other way round...)? If you are not shure about the licensing, why not ask Alco Blom, the author of 'URL Manager' <http://url-manager.com/version270.html> ? Greeting, Michi

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

Should we try to get this in for 6.5? I think so....

Putting on the Mozilla .9 train

dagley, don't touch my milestones. if you want it for 0.9, either indicate with a keyword or take the bug yourself.

For the record: Opera tp2 supports shared menus and the latest beta version of URL Manager supports Opera. <http://url-manager.com/version270.html>. Alco Blom helped the Opera team with his knowledge and maybe some code. Why does this take so much longer for Mozilla? Greeting, Michi

Setting target milestone to 0.9.2 (check it in anytime, even before, when the tree is open for). Per PDT triage.

Moving to 0.9.3.

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

Seems like the fix is there, but 1) you're unsure about licensing of the code and 2) someone's got to take the responsibility (reviewing the code and looking out for problems). This is a show stopper for me, so if there is anything I can do to help, please let me know...

I really *love* the lastest version of Mozilla Mac (.94) but am so bummed that neither it, nor Netscape 6.1, support the Shared Menus function so that I can use URL Manager Pro with them, as I can with IE, Opera, iCab and Netscape 4.7x. Is there a place, e-mail, where I can lobby for this feature? For years I've been able to move easily between browsers I'm trying, always taking my URLs and bookmarks with me, because of URL Man Pro. The author of URL Manager Pro, Alco Blum, is very responsive to requests for support too -- I beta tested his first version for Opera. But he says he can't do anything about Mozilla or Netscape 6.x until they support what he called the Shared Menus feature. I would love to start a groundswell of support for this addition, so I hope this post helps. Steve

Oops, accidentaly set to 0.9.7 when I meant 0.9.6 as I'd like to see it land before I go on sabbatical

Missed 096, no current activity. Please retarget appropriately.

->0.9.7

I'm back from sabbatical but this isn't going to make 097

really moving to 098 this time

sorry folks, not a high enough priority to stay in 0.9.8 -> 0.9.9

Just noting that Alco Blom is hosting the Carbonized Menu Sharing Toolkit sources at <http://www.url-manager.com/MenuSharingClient.zip> and they will be required for building when this code goes in.

Moving to Moz1.0 since this is going to need the build system update going in post Moz0.9.9 branch

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

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

Comment on attachment 17098 [details] Menu Sharing API Obsoleting per Comment #10.

Comment on attachment 17108 [details] docshell.mcp Obsoleting per Comment #10.

Comment on attachment 17109 [details] docshell.mcp Obsoleting per Comment #10.

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

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

With help from Alco Blom and his new CarbonEvent based SharedMenus.component (not yet released) this patch implements shared menu support in FizzillaCFM

Moved CheckSharedMenus() call in nsMacMessagePump::DoIdle() so it happens even if the mouse hasn't moved

Comment on attachment 102227 [details] [diff] [review] Shared menus for OS X sr=sfraser

Comment on attachment 102227 [details] [diff] [review] Shared menus for OS X r=bnesse.

As a point of reference SharedMenus.component version 1.2 is required for shared menus functionality to work in Mozilla. As of 10/18/2002 that version hasn't been released as a final build yet.

Is this something that can go into Chimera as well?

Checked in. Chimera has a seperate bug #171004 logged for shared menu support since none of this code is applicable. And as long as I'm being verbose, if someone needs the Carbonized Menu Sharing files for building Mozilla you'll find them at <ftp://ftp.url-manager.com/pub/MenuSharingClient.sit.bin>

Why is this being limited to Mac OS X ? The bug was originally filed for Mac OS 8.6. In the real world, most Mac users still do not use Mac OS X, and Mozilla supposedly supports Mac OS 8.6 and higher. In 12-18 months from now, the majority of Mac users will still not be using Mac OS X IMHO

> And as long as I'm being verbose, if someone needs the Carbonized Menu Sharing > files for building Mozilla you'll find them at > <ftp://ftp.url-manager.com/pub/MenuSharingClient.sit.bin> Judging from the folder names, 'MenuSharingClient' actually already includes support for 68k, PPC, and Carbonised applications. So there seems to be no good reason for not adding Menu Sharing to pre-OS X versions of Mozilla and Phoenix.

I'm not sure where you got your data, and I doubt your 18 month projections. In any case, users of old machines and operating systems are extremely unlikely to be upgrading their applications. In the real world, developers are rapidly dropping support for MacOS 9, let alone 8.6.

Here's my comment in SUPPORT of including shared menus in Mac OS 8.6+ as the bug was originally assigned. If I interpret the older comments correctly, this feature "slipped through the cracks" in some early builds and in the process of getting it back on track it was reassigned to OS X without creating a separate bug to handle the Mac OS 8.6+ builds. I have two opinions on recent comments, regarding the shared menus FEATURE and the browser MARKET -- FEATURE: Shared menus is important to me -- I use Alco Blom's Web Confidential, and it would be useful to have its browser menu work as designed. MARKET: This Mac OS 9.2.1 system is running Mozilla. Many people use Mozilla on pre-OS-X systems and I personally refer more users to Mozilla (on all platforms) every day. Although any NEW Mac I may purchase in the future will use OS X, plenty of older machines that are still used daily (including this 1998 vintage WallStreet PowerBook) will NOT be updating to OS X. Schools, nonprofits, and new owners of hand-me-down systems could constitute a widening of the Mozilla base over the next few years because it's a very good, viable browser, and OS versions 8 to 9.1 cover all PPC Macs. iCab is another good browser for older systems and it may have smaller memory and disk requirements. It is not free, however, and it is not the leader that Mozilla has become. P.S.: Thank you to the intrepid folks who have taken the time to get this bug back on track, if only for OS X! I hope it can get into the 8+ builds, too.

I just added bug 173507 asking for Mac OS 8.6 to 9.x support for the Menu Sharing API so others interested can vote for it.

adt1.0.2+ from conversation in ADT meeting

To test this feature you'll need to download the following: ftp://ftp.url-manager.com/pub/osx/url-manager-pro-30.dmg.bin and ftp://ftp.url-manager.com/pub/SharedMenus.component.sit.bin 1) After decompressing SharedMenus.component.sit.bin place it in ~/Library/Components (create a Components directory if one doesn't exist yet). 2) Decompress & mount the URL Manager Pro 3.0 disk image and copy the URL Manager Pro 3.0 folder to /Applications/Utilities 3) Launch URL Manager Pro from /Applications/Utilities/URL Manager Pro 3.0 4) URL Manager Pro should display a window named 'Sample' which is its default sample bookmarks file 5) Launch a build of Mozilla with shared menu support and observe that 2 menus are added after the normal menus - one with a diamond icon and one named Sample 6) Select a bookmark from the Sample menu and note a new window opens with that bookmark 7) Select Add Bookmark... from the diamond menu and note that a dialog appears allowing you to create a new bookmark (add it to the default 'Drop Basket') 8) Note that there is now a Drop Basket submenu under Sample and the bookmark you created is there 9) Select the new bookmark and observe it is loaded in a new window

Verified in the 2002-10-18-08 trunk build under 10.2.1

Comment on attachment 102227 [details] [diff] [review] Shared menus for OS X a=rjesup@wgate.com for 1.0 branch; change mozilla1.0.2+ to fixed1.0.2 when checked in.

Verified in the 2002-10-23-05 OS X branch

Any chance to get the CFM build instructions on mozilla.org updated? I'm sure a lot of people trying to build a Carbon CFM build are running into it.