Created attachment 260445 [details]
Grub configuration file with produced me the traceback

Created attachment 260446 [details]
Grub configuration file

Oops, I attached previous wrong configuration file.

Attila, what braille table are you using? Because you have the following right before your braille tracebacks:

generate braille results:
  Text: '│││ $$end !,etc!,grub.d!,#da'-custom ### ', -1223511168
BRAILLE LINE:  '│││ $$end !,etc!,grub.d!,#da'-custom ### '
     VISIBLE:  '│││ $$end !,etc!,grub.d!,#da'-custom ### ', cursor=0
sayLine: line=<### END /etc/grub.d/41_custom ###>, len=33, start=8922, 
caret=8955, speakBlankLines=True
SPEECH OUTPUT: '### END /etc/grub.d/41_custom ###'

What I have is no tracebacks and the following instead:

generate braille results:
  Text: '### END /etc/grub.d/41_custom ### $l', 33
BRAILLE LINE:  '### END /etc/grub.d/41_custom ### $l'
     VISIBLE:  '### END /etc/grub.d/41_custom ### $l', cursor=34
sayLine: line=<### END /etc/grub.d/41_custom ###>, len=33, start=8922, 
caret=8955, speakBlankLines=True
SPEECH OUTPUT: '### END /etc/grub.d/41_custom ###'

Hi joanie,

Jay, I forgot to wrote:
My Orca preferences enabled the contracted braille feature, and I use with hu-hu-g1.ctb hungarian grade 1 Liblouis braille table.
Liblouis version in Saucy and Ubuntu 14.04: 2.5.3-2
Brltty version in Saucy: 4.5-3ubuntu1
Brltty version in Ubuntu 14.04: 4.5-3ubuntu2

In console I using the hu.ttb Brltty table, so in Brltty preferences, this table the selected table.

If you need other informations and tests, I will be doing tomorrow morning the required tests.

Attila

I forgot to ask:
Since I think Ubuntu 12.10 I fighting this mistifical Brltty exception when I using Orca:
brlapi.OperationError: <unprintable OperationError object>
What meaning this error for Orca side? In Ubuntu 12.04 I fine using with Liblouis latest 2.5.3 and trunk release with Ubuntu 12.04 awailable Brltty without any problems.

Thanks. I'm now closer in that my braille results look much more like yours:

generate braille results:
  Text: '│││ $$end !,etc!,grub.d!,#da'-custom ### ', 40
BRAILLE LINE:  '│││ $$end !,etc!,grub.d!,#da'-custom ### '
     VISIBLE:  '││ $$end !,etc!,grub.d!,#da'-custom ### ', cursor=40
sayLine: line=<### END /etc/grub.d/41_custom ###>, len=33, start=8922, 
caret=8955, speakBlankLines=True
SPEECH OUTPUT: '### END /etc/grub.d/41_custom ###'

The one exception is that where I have "40" as the cell position, you have
"-1223511168". I still cannot reproduce this bug yet, but I'll see if I can
figure out where that bogus position might be coming from.

As for your other comment, when Orca tries to talk to brltty via brlapi and encounters an error, it prints out whatever error it gets from brlapi. If I can reproduce this bug I'll see if I can get something out of the OperationError that is more meaningful.

The difference with braille position is very interesting and suspicious me. You using now Fedora for testing?
Your distribution what Brltty version and Liblouis version are awailable? Possible Ubuntu packaged an oldest Brltty version or have a problem with Brltty BrlApi python binding for Ubuntu level?
Unfortunately GNOME related Ubuntu 13.10 have some "mixed" components, so Saucy not ship a full clean GNOME 3.8 environment.
Now my reinstalled Saucy testing system I not upgraded yet with GNOME 3.10.
I have got an old Alva Satelite 570 pro 71 cell braille display.

Attila
Attila

Created attachment 261220 [details]
Debug file with not enabled contracted braille

Hi Joanie,

To restrict Liblouis problem, I turn off temporary with contracted braille feature in Orca preferences, attaching the second debug.out file.
Unfortunately I experienced equals results if contracted braille not enabled. Have difference the braille positions?

Attila

Created attachment 262809 [details]
Detailed debug output

Hi Joanie,

I sending you a detailed debug.out file.
I removed temporary in src/orca/braille.py file the braille related debug outputs. Tracebacks more detailed now.
For example, an interesting part:
Traceback (most recent call last):

+ Trace 232836

Hopefuly this debug output help identifying what the correct problem.
I wrote a letter friday with Brltty list this problem related, not get yet any answer. Unfortunately I experienced similar issue with Brltty latest svn revision.
A more interesting thing, I not see now this debug.out file the IndexError: list index out of range related traceback message. Possible this is a false traceback message previous.

Attila

Hi Joanie,

I have got a bad news:
I think this issue is not absolute sure Brltty related issue. I tested following thing in text console:
I simple press CTRL+ALT+F1 key combination, and log in. After this, I opened the grub.cfg file with nano text editor. Simple scroll end of the file, and begin scrolling up arrow line by line. Every lines I see right my braille display with I previous not see with Orca my braille display.
After this, I repeated this test in Gnome Terminal with Nano. Unfortunately when I navigate end of the file and begin scrolling up arrow with line by line, braille display presented with "screen not in text mode" text, and I not hear the highlighted lines with my speech sinth.

Attila

I'm not saying this bug is just a brltty issue. I think something bad is going on that will need to be changed in Orca. But whatever that thing is, I think it might be crashing brltty. And crashes should not happen even in the case of bad behavior.

Attila, from your debug.out I see that the following text got written to your terminal and I'm curious as to why:

vvvvv PROCESS OBJECT EVENT object:text-changed:insert vvvvv
OBJECT EVENT: object:text-changed:insert               detail=(597,434,   func_fdtransform = lambda _, cond, data: func(channel, cond, data)

+ Trace 232841

)
    app.name='gnome-terminal' name='Terminal' role='terminal' state='enabled focusable sensitive showing visible' relations=''
Script for event: gnome-terminal (module=orca.scripts.apps.gnome-terminal.script)
TOTAL PROCESSING TIME: 0.0018
^^^^^ PROCESS OBJECT EVENT object:text-changed:insert ^^^^^

This is interesting.
Realy when I created debug.out file always I doed following:
1. In terminal typed orca --replace --debugfile=anything.out & command.
2. Run gedit grub.cfg command, repeated the testcase.
3. Exit with Orca to the debug.out file full closed (unfortunately I don't no why orca --replace command producing truncated debug.out file).
4. Attach the debug file with the report.

If I missunderstand anything, sorry.
What the next step?

Attila

Other questions since I cannot reproduce this issue yet:

1. In braille.py, the _brlAPIKeyReader() method calls shutdown() if there is an
error. Does commenting out the shutdown() line make any difference? (I don't
think it will solve the bug, I'm merely asking if it helps, makes things worse
or has no impact.)

2. At the same time you are using Orca, do you also have a console running and
using brltty? If so, does it make any difference if you do not have that
console running and using brltty when using Orca to reproduce this bug?

Hi Joanie,

I tryed uncommenting the shutdown related line with you wrote code part, but unfortunately nothing changed my system.
When I making the debug.out files, I not logged in any text consoles, I working the TTY7 console, this is my graphical console by default.

Attila

I have created an Ubuntu Saucy environment, set it up with the Hungarian locale, and I still cannot reproduce your bug without making a bogus change to Orca. Which brings me to the following:

My braille display is also an old Alva, but with 40 cells -- technically 43, the first three being status cells. And Orca is getting the size (width of 40 cells) correctly via brlapi. And no bug happens. However, if I go into braille.py and on line 1745 turn _displaySize = [x, 1] into _displaySize = [x+5, 1] Orca thinks I have more cells than I really do and in that case I see the very same bug you do. If on the other hand, I turn it into _displaySize = [x-5, 1] Orca thinks I have fewer cells than I really do, but the bug does not happen.

Could you please do the reverse of my experiment, i.e. make the line _displaySize = [x-5, 1], and see if that changes anything?

Sorry and thanks! (I'm really trying to get to the bottom of this....)

Hi Joanie,

I doed following modification without good result my machine:
diff --git a/src/orca/braille.py b/src/orca/braille.py
index 7da3c48..b2cdb02 100644
--- a/src/orca/braille.py
+++ b/src/orca/braille.py
@@ -1742,7 +1742,7 @@ def init(callback=None, tty=7):
     #
     #_displaySize = (brl.getDisplayWidth(), brl.getDisplayHeight())
     (x, y) = _brlAPI.displaySize
-    _displaySize = [x, 1]
+    _displaySize = [x-5, 1]
 
     # The monitor will be created in refresh if needed.
     #

Unfortunately nothing changed my system.
After this, sure by sure I created a new user to restrict possible corrupted preferences. Again setup Orca preferences and enabled only Brltty level braille support to restrict Liblouis related issue.
Orca right detected the changed display size (65, 1, original value my display with Orca detected is 70, 1).
My display size is realy a 70 cell braille display.

In Brltty preferences menu the status cell preferences default my system the None position is setted, I not changed this preference. Possible values is left, right, none.
The text style related preference in the braille presentation preference section default setted with 8 dots. I tryed change this preference with six dot computer braille without good luck.

I not have other ydea now why happening this error my system, very interesting to you not reproduced this error.
You installed any newest components your Saucy environment except Orca master version (newest Brltty, newest Liblouis release)?
I not upgraded yet with Liblouis the actual trunk release.
If you have another ydea with need testing, I will be doing the proper test.

Attila

Created attachment 262916 [details]
Another debug file when I looking .local/share/orca/user-settings.conf file

Ok, I think I begin founding the problem root.
I simple opened my .local/share/orca/user-settings.conf file, press CTRL+END keystroke, and begin reading line by line with up arrow keypress.
Until the original text middle part not containing a # character, everithing works fine.
Looks following little output part:
generate braille results:
  Text: '        (mag$cursor$color): (│#jjjjjj),  ', 1
BRAILLE LINE:  '        (mag$cursor$color): (│#jjjjjj),  '
     VISIBLE:  '        (mag$cursor$color): (│#jjjjjj),  ', cursor=2
sayLine: line=<        "magCursorColor": "#000000", >, len=37, start=8535, 
caret=8536, speakBlankLines=True
SPEECH OUTPUT: '        "magCursorColor": "#000000", '
TOTAL PROCESSING TIME: 0.0428
^^^^^ PROCESS OBJECT EVENT object:text-caret-moved ^^^^^

BrlTTY seems to have disappeared:

Traceback (most recent call last):

+ Trace 232842

I tryed an another thing in Gedit:
Typed first line a normal line, text is Hello Joanie.
Typed second line before this text a # simbol.
The third line containing the # simbol with the middle position to Orca presenting the hassmark character with contracted braille.
So the text file is following:
Hello Joanie
#hello joanie
test ###hello joanie
I experienced following when I used contracted braille with Orca, everi line reading the cursor position have the first character:
When the caret first land the Hello joanie text, everithing is works expected, I see right the braille result.
When the caret lands the second text, I get same good result, because Orca using with louis.CompBrlAtCursor mode. This is resulting the cursor highlighted word presenting in computer braille.
When the caret lands the last line, my braille display presented the "screen not in text mode" text. After this, I unable to scroll with arrow keys, I not hear speech output.

Can you try this short test for example an english grade1 table when contracted braille enabled your machine?
I not reproduced this issue when contracted braille enabled with english grade1 table. Very interesting hungarian grade1 table why producing this issue, this character mapping not changed the table.
I need doing more resealc this thread part related.
When I ran following code my Saucy environment in Python 3, Liblouis translateString function generated the # character braille simbol with \x2502 character, I don't understand why:
import louis
text="#"
trans=louis.translateString(['hu-hu-g1.ctb'], text, None, 0)
print('The hassmark simbol translated braille character: '+trans)

I verifying this code my oldest Ubuntu 12.04 system, this system passed the wrote text file test with hu-hu-g1.ctb table when contracted braille enabled with Brltty 4.4 and Orca 3.4.2 version.

Attila

Ok, I researched little:
Because hungarian grade1 standard require to contracted braille presenting 123456 dots when normal # characters have a normal text, in Liblouis source tree the tables/hu-chardefs.cti file have following rule:
punctuation	│	123456	BOX DRAWINGS LIGHT VERTICAL
In /etc/brltty/boxes.bti file have following rule this simbol:
glyph \u2502	(12345678)  # ⣿ │ [BOX DRAWINGS LIGHT VERTICAL]
Oldest Brltty 4.4 release when a text containing the # character presenting the 12345678 dot combination. Now I tryed owerwrite this rule in /etc/brltty/hu.ttb table with following rule:
glyph \u2502	(123456)  # ⣿ │ [BOX DRAWINGS LIGHT VERTICAL]
In console, this rule is works right when I ran my Liblouis translation code, right the 123456 dots presenting my braille display.
When I run this code in gnome-terminal and Orca, not brovsable with braille line moving keys the prewious line with presenting the result.

When I looking the previous comment wrote text file last line, nothing changed unfortunately.
When the caret lands the last line, Brltty crash.

Attila

Hi Joanie,

I wrote Mesar with following letter, oldest time we lot of time working together with Liblouis hungarian table and other Liblouis related testing tools.
Hopefuly Mesar will be have a good ydea.
Following my letter:
"Hi Mesar,

My Ubuntu Saucy environment if I using the hu-hu-g1.ctb table with Orca master branch version, if a text file containing a # character not the actual cursor position, happening a traceback message.
Example text with reproduced this problem:
Hello Joanie
#hello joanie
test ###hello joanie

I already researched the possible thing why happening this issue, but I don't no how can resolve this issue:
The hungarian grade1 standard require the # character presenting dot combination with 123456 dots, this is not changeable.
The tables/hu-chardefs.cti file have following rules this standard related:
The 53 th line containing following rule, require this with numsign indicator:
sign # 3456

The hu-chardefs.cti file have following rule in the 107th line to define the 123456 dot:
punctuation	│	123456	BOX DRAWINGS LIGHT VERTICAL

Final, the hu-hu-g1.ctb have following rule:
always # 123456

This rule implementation way not produced problems with Orca 3.4.2, Liblouis any versions and Brltty 4.3-1ubuntu5 version in Ubuntu 12.04, except Brltty presenting the # simbol when contracted braille enabled with 12345678 simbol.
This is resolvable future, but not resolving this interesting bug with Orca the hu-hu-g1.ctb table related.
In /etc/brltty/boxes.tti file have following rule:
glyph \u2502	(12345678)  # ⣿ │ [BOX DRAWINGS LIGHT VERTICAL]
If I using following rule the hu.ttb table, presenting right six dot the # character when I do a louis.translateString function:
glyph \u2502	(123456)  # ⣿ │ [BOX DRAWINGS LIGHT VERTICAL]

If I ran following code in Python3 and try browsing braille flat review the generated output line, I not see the Liblouis generated braille result line and braille scrolling freeze:
import louis
text="#"
trans=louis.translateString(['hu-hu-g1.ctb'], text, None, 0)
print('The hassmark simbol translated braille character: '+trans)

In console I right seeing the generated output, the # character presenting with 123456 dots if I added the wrote modification with /etc/brltty/hu.ttb table.

If I commenting out the always # 123456 rule in the hu-hu-g1.ctb table, everithing is works right with Orca in Gedit, except the # characters presenting with 3456 dots, this is not good fix way.

In Ubuntu 13.10 awailable following components:
Brltty version: 4.5-3Ubuntu1
Liblouis version: 2.5.3 (already I looked the master svn version)
Orca version: I using Orca master branch version with testing purpose"

Attila

Created attachment 268080 [details]
Another debug.out file with related Firefox braille usage

I see unfortunately this issue with Firefox, hiperlink containing text producing unfortunately Brltty crash.
Testcase:
1. Open http://vakbarat.index.hu/belfold/budapest/2014/02/04/mozgasserult_utason_gunyolodott_a_villammosvezeto website.
2. Try reading the article with arrow key, and listening the braille text.
After Orca spokening following text and I press down arrow key, Brltty crash:
"akarta kérni a járat számát, hogy panaszt tehessen, de ezt nem mondta meg. Ehelyett becsukta az ajtót, és a férfit magával vitte a remízbe, annak ellenére,"

The next line containing normal text and a hiperlink.
Braille line with Orca I don't no why not presenting the braille display in Firefox:
hogy a2 #eh 1ves $g"bor kifeje2etten tiltako2ott e2 ellen - |rja a $blikk, a cikk c|m1ben e4enesen t05ejt1sk1nt 1rt1kelve a villamosve2et7 akci9j"t.

Normal text:
"hogy az 58 éves Gábor kifejezetten tiltakozott ez ellen – '
írja a Blikk, a cikk címében egyenesen túszejtésként értékelve a villamosvezető akcióját."

Joanie, have any ydea why happening this situation this magical issue?
Unfortunately the crash is the magical brlapi.OperationError: <unprintable OperationError object> exception.

Attila

Created attachment 268130 [details] [review]
Proposal fix

Hi Joanie,

I not want happy too early, but this modification me resolved the yesterday wrote Firefox related testcase. :-):-)
Can you review this patch? Safe this fix your openion?

If I using this patch, I fine readed Orca the linked article only my braille display without any errors, Brltty not crashed me. This is a fantastic feeling, since have this type error, I disabled the braille support and I only using braille support when need testing a braille related bug.

Note: I searched some "UTF-8" strings with grep in main orca source codes. Not need examining this code parts future?
braille.py:        writeStruct.text = bytes(substring, 'UTF-8') (I changed this code line)
debug.py:    procs = procs.decode('UTF-8').split('\n')
eventsynthesizer.py:    - keystring: an (optional) UTF-8 string which, if keyval is NULL,
input_event.py:        # mapping ASCII control characters to UTF-8.]]]
keynames.py:# __keynames is a dictionary where the keys represent a UTF-8
messages.py:# Translators: We replace the ellipses (both manual and UTF-8) with a spoken
orca_bin.py:        stringBuffer.value = bytes(name, 'UTF-8')
orca.py:    lines = _originalXmodmap.decode('UTF-8').split('\n')
orca.py:                    _setXmodmap(bytes('\n'.join(lines), 'UTF-8'))
orca.py:                    _setXmodmap(bytes('\n'.join(lines), 'UTF-8'))

Python3 not handle default strings with UTF-8?

Attila

Comment on attachment 268130 [details] [review]
Proposal fix

(In reply to comment #22)
> I not want happy too early, but this modification me resolved the yesterday
> wrote Firefox related testcase. :-):-)

Yay and congrats!!! I went ahead and committed it. You still seeing the issue in your opening report?

No, the last commit entire resolved this bug. Your openion other scripts subdirectory have Orca braille codes have chance to keeped this changed buggy line?
Possible affected codes (simple find collection):
./toolkits/WebKitGtk/braille_generator.py
./toolkits/Gecko/braille_generator.py
./apps/soffice/braille_generator.py
./apps/planner/braille_generator.py

Sure by sure when I doed a regression testing, I detailed verifyed the original Gedit related issue with contracted and uncontracted braille support, and again readed the linked test article in Firefox both uncontracted native Brltty support and contracted braille support before I changing this bug state.
Both two Orca braille modes works great now.
This situation not need doing a newest correction release?

Attila

(In reply to comment #24)

> No, the last commit entire resolved this bug.

Woo hoo! Nice job and thanks!! I don't understand this question though:

> Your openion other scripts
> subdirectory have Orca braille codes have chance to keeped this changed buggy
> line?
> Possible affected codes (simple find collection):
> ./toolkits/WebKitGtk/braille_generator.py
> ./toolkits/Gecko/braille_generator.py
> ./apps/soffice/braille_generator.py
> ./apps/planner/braille_generator.py

What in particular? What braille.py does is actually send stuff to the display. (The generators determine what should be sent.) So what you fixed was a bug in sending stuff to the display that made brltty very unhappy. That's has nothing to do with the generators.

> This situation not need doing a newest correction release?

You mean do yet another 3.11.5 unstable release? No. Your fix will go into the next unstable release. Correction releases (like the 3.11.5.1 I did) only happen if a release is badly broken and should not be taken by distros. Fixing a bug is not the same as a badly-broken release.

Hi Joanie,

I think in Orca list oldest time you talked Luke need future an unofficialy Orca 3.10.3 version, because Ubuntu 14.04 will not updating Orca version to the 3.12 version (I very sadly).
Possible adding following braille related commit this unofficialy version?
commit 12288676c11df8deb5e28798b0865a425d94a3b5
Author: Attila Hammer <hammera@pickup.hu>
Date:   Wed Feb 5 09:36:15 2014 +0100

    Fix a mysterious Brltty crash triggered by Orca

Without this commit Orca 3.10 version producing misterious Brltty crash, the committed patch changing I think one line in src/orca/braille.py file.

Attila

Done. Thanks for the reminder!