I see bugs open on changing around the edit/go/tasks menu, but nothing on Debug/QA menus. They're currently less the useful, and most of the links in them are to buggy demos, etc. If we're going to have some global pulldown menu in every build, we should probably make it a little nicer. Incoming patch.

Debug menu was screwed harder in the process, but it's not much worse. Until I can figure out what in the debug menu even works (most don't for me) and clean it up, this is a major improvement overall IMO. Screencap of the patch: http://turbogeek.org/mozilla/debug-qa-patch.png

some Items in the QA and debug menu are working only if you select special build options. Why do you remove the bloat entrys ? They may work with special build options.. If some tests are not working, we should fix the tests

> Why do you remove the bloat entrys ? They may work with special build options. Check the patch. They're not removed, they're under debug, where they belong (if they do indeed work at all). > If some tests are not working, we should fix the tests I've filed many many bugs on problems in the test pages... they've all been futured. Until they're fixed we're better off removing UI for them to avoid confusion. They'd still be accessible in the tree, but if your providing UI, they damn well better be good comprehensive tests, which work... which they aren't and don't.

Looks like fun. --> jmd, XP Apps: GUI.

gerv's approval == my sr

I'll look at this ASAP. It definitely needs doing, although there may be the odd tweak I'd like to make. Gerv

Comment on attachment 68623 [details] [diff] [review] Step 1: make the QA menu useful to QA people >+ <menuitem label="chofmann's browser buster" oncommand="window._content.location.href='http://komodo.mozilla.org/buster/'"/> "chofmann's Browser Buster". >+ <menuitem label="Composer with test page" oncommand="window.openDialog('chrome://editor/content','_blank','chrome,all,dialog=no','chrome://editor/content/EditorInitPage.html')"/> "Composer (with test page)". >+ <menuitem label="Known Bugs" oncommand="window._content.location.href='http://bugzilla.mozilla.org/duplicates.cgi'"/> "Frequently Reported Bugs". >+ <menuitem label="Bug Writing Guidelines" oncommand="window._content.location.href='http://www.mozilla.org/quality/bug-writing-guidelines.html'"/> >+ <menuitem label="File a Bug..." oncommand="window._content.location.href='http://www.mozilla.org/quality/help/bugzilla-helper.html'"/> Should be ".../bug-form.html". This means we check that JS is turned on. And remove the ellipsis. No dialog opens. Other than the above, excellent. Well done :-) Fix those and r=gerv. Gerv

Using "Frequently Reported Bugs", that link is now the longest entry and makes the menu a bit wider then would be ideal. How about "Most...", "Commonly...", or "Often...". None of those sound that great, "Frequently..." included. Any better ideas anyone? > Should be ".../bug-form.html". Good catch, didn't notice I changed that. > Other than the above, excellent. Well done :-) Wow, I expected opposition. That menu's sucked so bad for so long I figured everyone liked it that way. :) Although, I suppose the more controversial stuff may come when I weed through the Debug menu. By the way, what's the threshold for adding oneself below "Contributor(s):". This is probably my largest change by line count, but it's all just string lits, no functional code changes. I don't see any guidelines for it.

For phase two... I'm wondering what attachments you all have to the verification, viewer, XBL, and XUL tests in the menus now. I'd like to remove them all. Here's why: a) They're big. Over 500k of disk used in a mozilla install, and about 200k extra of compressed download. That's about a minute extra for a modem user. b) They're broken. There's bugs filed on five of the six XBL tests. All five bugs are futured. Other sets of tests are similarly problematic. c) They're not at all comprehensive. No one's really finding any bugs with them. They might have been useful back in the M5 days, but there's enough users around now that any bug that could be found in these simple tests (that no one is using), it will also *easily* be found in the wild somewhere on the web. d) There's no reason we need 45 hard-coded links in the main menus to test-pages. If we had a decent test suite, it would be much better served by an on-line web page linking to the differant components. With those removed, the debug menu is pretty close to being disableable on non-debug builds. Only composer test page, browser buster, and wallet samples would remain, which should be easy enough to put into better places.

> "Frequently" and friends "Often-reported" might do. But I wouldn't get too hung up on menu width - this is only a problem if there are submenus, which I believe your design doesn't have. > removing tests? I suggest you mail the component owners for the areas, and also post to porkjockeys. I see no reason, in principle, for turning them into a www.mozilla.org web page. > By the way, what's the threshold for adding oneself below "Contributor(s):". There is none. You can add yourself if you changed the file. In this case, it's certainly a big enough change. Another thought: you need to make sure the smoketesting document is updated to reflect the new menu structure if necessary. Gerv

I left it "Frequently", to match the page content. Everything else fixed. Added a few more whitespace cleanups and untabification. > make sure the smoketesting document is updated to reflect the new menu > structure if necessary Not necessary. It only points to one thing in the Debug menu, and it's still there, for now. r=gerv, sr=blake should still apply.

Comment on attachment 69348 [details] [diff] [review] Step 1: QA menu - with revisions This can be checked in by anyone who has the time and inclination. I'm off to Brussels :-) Gerv

doesn't really block bug 108099, but want to add it to the dependency tree to make it easy to keep track of...

> This can be checked in by anyone who has the time and inclination. I already had timeless check it in last night. Have fun in Brussels. Going to start work on the Debug menu... > I see no reason, in principle, for turning them into a www.mozilla.org web page. Did you mean "for *not* turning"? I'll get in touch with porkjockeys et al...

I did mean "not turning". One bug per issue - please resummarise and close this bug, and open another one for Debug. Good work :-) Gerv

http://www.mozilla.org/quality/help/bug-form.html instead of http://www.mozilla.org/quality/bug-form.html Gerv's .../bug-form.html meant he didn't want to type http://www.mozilla.org/quality/help, not that you should go to the parent directory... Also the elipsis is still there even though you said "Everything else fixed."

Thanks Peter... I accidentally attached an earlier version of the patch.

Checked in. We're done here. Gerv wants a new bug for Debug menu work.