+1. My only concern is that it must be easy to filter or ideally prevent from
being added bugs that are duplicates; otherwise, we will be overwhelmed.

As for the server side of this equation, is it possible to have some kind of Web
service (SOAP over HTTP; REST; email; ftp) available for IssueZilla from
collab.net? If not, any implementation of this feature would require
screen-scraping (yuck).

There was a module sim/bugsubmitter that tried to do this. Never really got
adopted, I think. Issuezilla has a primitive sort of web service interface.

Having a menu item to file a bug is probably not as useful as it sounds. Most of
the interesting information which *could* be captured automatically is already
in the log file, which can be attached pretty quickly. It is possible that the
IDE could track some important events occurring right before the error occurred
(if there is such a discrete point in time), but it's not at all obvious which
events are "important". If it's a code completion bug, probably every editor
keystroke matters - as well as the contents of the open file and your project
setup. For a NullPointerException thrown when trying to open some dialog, the
cause could be corrupt data in the user dir, or a buggy version of Swing, or a
transient network drive failure, or the fact that the user closed the same
dialog using the window close button (rather than Cancel) an hour ago. Or
something may have gone wrong a couple of days before and the user is only now
seeing the symptoms.

The main problem with making bug submission too easy is that everyone will file
bugs too casually. Having duplicates is not a big deal (they are not much work
to close as such), but having "junk" bugs (e.g. a log file with summary "error"
and no description) tends to make developers consume more time trying to process
new bug reports than making real fixes to bugs which are already known. Useful
bug reports have to be concise and often need to give reliable steps to
reproduce from scratch. This is not always simple; in one case it might be
enough to just dumping a stack trace into a bug report, but in another case you
might need to spend an hour or two distilling a complex setup into the actual
procedure that fails to work. Frequently the developer will need to request more
information from the user, such as running with some special logging flags
enabled which should not normally be enabled for performance reasons. Someone
selecting a menu item and typing a couple of sentences before pressing "submit"
is likely not interested in accepting this extra work. Anyway people get better
at submitting good bug reports the more experience they have, just like anything
else. Eric Raymond has an excellent essay that illustrates why this is so.

One promising area is not bug submission as such, but capturing of "crash"
reports. Java apps rarely crash hard but they often throw uncaught exceptions or
assertions. These can probably be collected mechanically and quietly from a wide
body of users (with their permission of course); any low-level error that occurs
at least ten times, say, automatically gets a bug report generated. Mozilla does
this, for example. We have considered it for NB, but no takers yet.

*** Issue 66667 has been marked as a duplicate of this issue. ***

*** Issue 72909 has been marked as a duplicate of this issue. ***

*** Issue 81416 has been marked as a duplicate of this issue. ***

Yarda is working on a gestures collector which IMHO is more useful than this.

Comments from reporter :

> I noticed that there is some activity around IZs 74562, 66667, 72909, 81416
> Does it mean that you are going to implement IZ 74562 soon?

A little bird told me, we probably will move in this area in the future (I am
not sure about the near one, but I believe we will) ;)

> Or the plan is to close all of them? :-)

I closed all of them, because more or less all are requesting for same
enhancement/feature. 

> I've been working with bugs for many years and I noticed that closing a P2
> issue as a duplicate of a P3 issue looks very "user unfriendly". :-) At least
> the priority of remaining issue should be be raised to P2 :-)

Agreed - raised priority here.

> Also closing issues as a duplicate of another *unresolved* issue does not
> really help, unless they are really duplicates (the same user filed the same
> issue several times), which is not the case here.

I am sorry, but I can't agree with you. Closing duplicates helps developers to
focus on one issue / instead of live with 4 opened.

> Looking at IZ 72909 I don't think it is a duplicate. It can reuse the same
> internal mechanism as IZ 74562 (assuming it is implemented!), but from
> user's point of view it is a different feature: it can be implemented as a
> button in "Exception" dialog - "Send Report".
> IZ 81416 suggests different UI (add menu item to Help menu).

Yes, as I said above, all are requesting same feature "more or less".

> If there is no plan to implement IZ 74562 really soon, all these changes
> look like a "busy work" from user's point of view. :-) Sorry about that.

Well, to be honest I don't know about any plan, but as I said above the number
of duplicate issues is rising so the number of users waiting for this feature
and this is good argument to make some progress in this area ... stay tuned.

File gdb/profiles/GdbProfile.java creates the Debugging node in project
properties:
  Debugging   |    Tool      |   gdb   [...]
(the word "gdb" is the default name of debugger, and user should be able to
change it with and without mouse)

I run the Netbeans accessibility test over this page, and it found several
a11y issues. None of them is related to the Debugging node itself, but I
cannot find a way to change the value of the Tool property without mouse.
If I select this entry and try to type in a new value, it opens a "Quick Search"
textfield, which is absolutely useless here, because it cannot find anything.
Context menu (Shift+F10) also does not work - it just beeps. I can open context
menu using right mouse button, but cannot open it without mouse.

Here is a report provided by the Netbeans accessibility module:

<TITLE>Output from UIAccessibilityTester for window with title : Project Propert
ies - Args1 </TITLE>
Results of Accessibility test, window with title "Project Properties - Args1"
 Doesn't implement Accessible :
   - none.
 No Accessible name :
   Class: org.openide.explorer.view.BeanTreeView {  |  }  [14,71]
   Class: org.openide.explorer.view.TreeView$ExplorerTree {  |  }  [14,71]
 No Accessible description :
   Class: javax.swing.JButton {  Manage Configurations... |  }  [213,38]
   Class: javax.swing.JComboBox {  Configuration: |  }  [85,40]
   Class: org.openide.explorer.view.BeanTreeView {  |  }  [14,71]
   Class: org.openide.explorer.view.TreeView$ExplorerTree {  |  }  [14,71]
 Label with LABEL_FOR not set :
   - none.
 Components with no LABEL_FOR pointing to it :
   Class: org.openide.explorer.propertysheet.SheetTable {  Properties table |  T
able of editable properties representing the current object }  [246,71]
   Class: org.openide.explorer.view.TreeView$ExplorerTree {  |  }  [14,71]
 Components with no mnemonic :
   - none.
 Components with wrong mnemonic (mnemonic isn't ASCII , label doesn't contain mn
emonic):
   Class: javax.swing.JLabel {  Configuration: |  }  [12,42]
 Components not reachable with tab traversal :
   - none.
-------------------------------------------------------------------------

I'm terribly sorry, the comments above have nothing to do with this IZ.
They appeared there by mistake (I edited another IZ, submitted changes, 
then added these comments, but did not notice that this "super smart" tool
changed the IZ to the next one from the list). If somebody knows how to
remove wrong comments, please let me know.

Thanks,
Nik

*** This bug has been marked as a duplicate of bug 173678 ***