124484 - Make QA menu useful to QA people

Status: RESOLVED FIXED

(SeaMonkey :: UI Design, defect)

Description

[Jeremy M. Dolan]

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.

Comment 1

[Jeremy M. Dolan]

Attachment: Step 1: make the QA menu useful to QA people

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

Comment 2

[Matthias Versen [:Matti]]

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

Comment 3

[Jeremy M. Dolan]

> 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.

Comment 4

[Matthew T (active 1999-2002)]

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

Comment 5

[Blake Ross]

gerv's approval == my sr

Comment 6

[Gervase Markham [:gerv]]

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

Gerv

Comment 7

[Gervase Markham [: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

Comment 8

[Jeremy M. Dolan]

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.

Comment 9

[Jeremy M. Dolan]

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.

Comment 10

[Gervase Markham [:gerv]]

> "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

Comment 11

[Jeremy M. Dolan]

Attachment: Step 1: QA menu - with revisions

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 12

[Gervase Markham [:gerv]]

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

Comment 13

[sairuh (rarely reading bugmail)]

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

Comment 14

[Jeremy M. Dolan]

> 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...

Comment 15

[Gervase Markham [:gerv]]

I did mean "not turning".

One bug per issue - please resummarise and close this bug, and open another one
for Debug. Good work :-)

Gerv

Comment 16

[Peter Henderson]

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."

Comment 17

[Jeremy M. Dolan]

Attachment: 1 line cleanup

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

Comment 18

[Jeremy M. Dolan]

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