Mail has removed its Debug and QA menus from the app for good. Now the Browser and Composer need to do the same -- not just for beta3, but until release. The reason being is that there needs to be a period of time during which the product is being tested exactly as it will be shipped - e.g. without debugging/QA aids, etc. The period between beta3 and RTM is perfect for this. this needs to be +'ed. I can fix it if matt is busy.

While this does need to removed for Netscape RTM, I'm not sure about the following points: 1) I would argue that they should certainly not be removed in Debug builds although that would require some makefile munging. Developers do use these prefs to do, uh, debugging which will still need to happen between now and RTM :-] (e.g. hyatt just asked me for something tonight that requires me to disable my XUL Cache. Yes, I could shut down, manually edit prefs.js, and restart, but ...) 2) To the degree that these are rarely touched by Netscape and Mozilla testers, I'm not sure if they need to be removed until close to RTM (not 6 weeks prior to that). 3) mozilla.org might never want to remove these (as long as they are useful). Has this been widely discussed? (Yes, I realize that Blake is a big part of mozilla.org. I just don't know the answer to this question).

(1) Yeah, I meant in shouldn't be in optimized builds. Which, as you said, would require some hackery. (I'd also forgotten about the debug pref panes) (2) Yeah, you're right. 6 weeks is too long. My only concern was that the menus were going to be removed like a day before RTM, and that conceivably (though the odds are sliiiiiim), the removal of the debugging aids would cause some problems. But then, the same argument could be made that in the 6-week period, if we did remove the Debug menu, some of the tests on it would start crashing, but since QA wouldn't be using the menu much anymore, no one would notice it. So I guess like a week in advance is fine. I'll file a new bug about putting them back in Mail after beta3, and then another one about removing all of them completely for RTM. (3) This was nsonly. Thanks.

So, should we add the build people to help with makefiles to this bug (aka Leaf/Granrose)?

nav triage team: +, P1 reassin to Radha

PDT agrees P1

could you assign a ns-internal person as qa contact, as I will not be able verify this?

qa contact to asa, who has access to commercial builds.

Does keeping the menus and prefs in mozilla builds and removing from the commercial build sound OK? To be more clear, mozilla, optimised and debug builds will have these menus and prefs. But commercial build, optimised and debug won't ahve it. If we agree on this, we don't have to hack with make files. let me know.

Well, there'd only be two actual hackers on this bug, you and Blake, so I think you need to ask in .seamonkey or .builds or similar. However, I know that many XUL developers need to disable the XUL cache, and I think some of the paint flashing pref is used often. It may be painful if these are not available when needed. (On the other hand, if they are only commented out in the XUL, they can be restored with a quick edit and re-zip, if someone needs them).

cc'ing ben & granrose team. Is it possible to comment out code in xul and js for optimised builds, but keep them for debug builds?

Fix checked in

Um, this seems to have affected the mozilla nightly linux build.

Asa: the 2000092406 linux build still has these menus, and the navExtraOverlay.css file which sets these two menus to 'display:none' is not part of the mozilla packaged bits. Please check again. However, there are a couple of outstanding issues (sorry, this is tedious). 1) Setting 'display:none' on a menu does not hide it on the Mac. Whether this is a bug or simply a fact of life for Mac menus, I don't know (mea culpa). Mike? Nonetheless, this wouldn't make the priority list for fixes before RTM, so I suggest that now that we are branched, you could delete the navExtraOverlay.css file, and simply comment out these two menus in the branched version of 'navigatorOverlay.xul'. This does however mean that Netscape developers building the branch (mozilla or full commercial) will no longer have this menu (but they could simply maintain their own local copy with comments removed). 2) Composer has its own separate debug menu. I have filed bug 53994 for that team to remove this menu for nsbeta3 and for rtm, however they see fit.

to hide menus on MacOS, set the hidden attribute to true. using style has no effect since menus are always display:none on the mac

For Linux: Based on the recent jar packaging documents, I was under the impression that I just have to add the file to jar.mn and don't have to add them to the Makefiles. It looks like this is not the case. I will do what it takes to make it effective in linux. For Mac: I will send a patch around.

nsbeta3++

John, I'm seeing this on one linux build but not the other. I'm guessing that the maybe the depend and clobber mozilla builds differ here. I think that the depend build (the second linux build to show up each day) that has this problem but the clobber build doesn't.

Can someone verify that this is Really working in linux and the problem is only in mac?

Asa is correct. The 8am build for mozilla contains different content in (at least) comm.jar, including content for help, activation and IM (oops). I will file a separate bug on getting the build process looked at on Linux. Radha: I think you can just proceed on this for the Mac aspect, and once the Linux build process for mozilla stops including navExtraOverlay.css, it will just work on Linux.

Filed http://bugscape.netscape.com/show_bug.cgi?id=2486 for the linux build issue.

i have a patch for mac menus to respect setting "hidden" in the xul, but am needing reviews. should be able to land this by 9/26.

Mike, setting 'hidden="true"' already works, doesn't it? Is there some case where it is failing?

john - in email, pink said that setting hidden="true" programmatically via script worked, but setting in the XUL did not.

It's working for me '<menu ... hidden="true">' is hidden on launch, and can be manipulated by script as well, at least in 9/22 opt. build. (or did something just break.).

oh, i thought it didn't work on toplevel menus. a quick scan of the code showed that it didn't look like it would work when set from xul. am i wrong?

awesome, i wonder how that works....hrm.....

John, Can you post a patch? Mike I would appreciate if you can try out John's patch and confirm that it indeed works on Mac. The problem seems to be gone in windows and linux. Thanks, Radha

you are right. i just tried it with the 9/25 build and setting hidden=true in XUL does in fact hide the menu. Wow, I wonder where that code is ;) Mac is good to go.

Mike : Simon made this work at end of July, I believe (if that's any clue on where the code is). Radha: Patch? I was just adding 'hidden="true"' to a top level menu in navigatorOverlay.xul.

I have checked in a fix that should behave well in MAc too. Marking Fixed.

(Oh, I hate to do this ...) There is one flaw in that neat trick where you overlay <menu id='qaMenu' hidden='true'/> from NavExtraOverlay.xul onto navigator.xul. That works fine while the browser window is up (or some other top-level window, e.g., mailnews). But, when there are no windows open, on the Mac, the un-overlayed version of the menu from navigator(Overlay).xul is shown as the system menu, including the QA and debug menus in fully functioning form. I don't want to jump the gun, but this is obviously no longer nsbeta3++ as it is far away from pull of the wire. (Phil, could you just minus this bug). We do need a resolution for RTM (and likely the most effective solution at that time is just to delete these menus from the branched navigatorOverlay.xul).

You betcha. nsbeta3- for the remaining part of the bug.

I imagine this trick would work, were hiddenWindow.xul amended to overlay navExtraOverlay.xul, but nuking these menus on the branch before RTM is probably still the way to go.

Alright! taking it again. Hopefully physically removing the menus will work in MAC.

Radha, didn't we fix this already on the branch? Even on the Mac?

Yes, I checked in to the branch too. But with Mac there is another problem which I think will go away only if I physically remove the menus. THe problem is, even though the menus don't appear on currently open browser windows, since mac has this hidden window concept, it appears on the system menus. As jrgm suggests, I think I have to physically take these menus out from navigatorOverlay.xul sometime before release. I may have to do this in the last minute, since physically taking away means no Debug and QA menu for none of the builds (mozilla,commercial opt/debug included)

It seems to work, that if you add <?xul-overlay href="chrome://navigator/content/navExtraOverlay.xul"?> to hiddenWindow.xul, then the default menu will have the Debug and QA menu items hidden, even when no other mozilla windows are open. But it may still be best to nuke these at the last minute, for the purposes of the NS6 release build (it's pointless to ship these at all in Netscape). However, as you note, that would mean that Mozilla M18 would lack these menus, and that's not a good thing. (What to do, what to do ...)

This is fixed in all platforms on the branch except for Mac. I have fix in hand. Resummarising

Fix reviewed by pinkerton. waiting for super review from ben.

Plus. It's reviewed and approved. PDT, please plus this.

PDT marking [rtm++]

Adding to cc ...

a=ben

jrgm, Added the suggested overlay to hiddenWindow.xul. Please try it out and let me know if that works. Hopefully this is done for now.

jrgm - can you verify this for the branch builds? Thanks.

(Dang. Thought I had done this anyways). verified fixed 9/13 mac branch bits. No debug menu even when there are no open windows (e.g. when hidden window is providing the menu). Thanks Radha.