Sometimes there are behaviors or bugs that you can reliably reproduce but we cannot. In these instances it is often helpful to have a "full debug.out" which contains all of the keystrokes you pressed, the accessibility events that were emitted, what was spoken and brailled as a result, and any errors that may have occurred.
Obtaining a "full debug.out"
There are different debugging levels and different options/strategies for obtaining a full debug.out. We should outline them all here. For now, however, here are two approaches:
Option 1: Likely what you need
Start orca by pressing alt+f2 then type: orca --debug. The file will be named in the format: debug-YYYY-MM-DD-HH:MM:SS.out. If you would like the file to have a different name other than the default use the --debug-file=name as in: orca --debug --debug-file=debug.txt.
After you have captured the info you need be sure to restart Orca normally with: orca (or orca -r) so the file won't get too large.
In your $HOME/.local/share/orca/orca-customizations.py file, add the following lines:
import orca.debug orca.debug.debugLevel = orca.debug.LEVEL_ALL # NOTE: If you do not specify a file, all output will go to `stdout` where it can be redirected to a file. import time orca.debug.debugFile = open(time.strftime('debug-%Y-%m-%d-%H:%M:%S.out'), 'w')
Quit Orca. Then relaunch it (and any offending applications), reproduce the problem, and quit Orca. This will cause the debugging output to be in a file in your home directory (or wherever you launched Orca from if you manually launch it). The file's name will begin with "debug" end with ".out" and have a time stamp in between. Now comment the lines above so that Orca will no longer be recording all of that debugging information. When you relaunch Orca the next time, things should be back to normal.
Note that if you use Orca in order to perform the above edits to your orca-customizations.py the lines, you will have two debug.outs (the first from reproducing the problem; the second from recommenting the lines). We of course need the first of the two.
Where To Send It
The resulting file will likely be quite large and thus rejected by the GNOME mailing list. You can instead send it directly to the developer who asked for it. Alternatively, you can attach it to a bug or make it available via a file-sharing service, pastebin, etc.