Samuel Thibault, on Tue 22 Nov 2016 14:36:54 +0100, wrote: > Ksamak, on Tue 22 Nov 2016 14:26:32 +0100, wrote: > > On Tue, Nov 22, 2016 at 01:40:43AM +0100, Samuel Thibault wrote: > > > Samuel Thibault, on Mon 21 Nov 2016 22:16:03 +0100, wrote: > > > > It however still reproduces in firefox, I'm having a look. > > > > > > I have submitted a patch to > > > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1319273 > > > > You think this behaviour originates from mozilla products? > > In the particular case I explained, yes.
I mean, in the particular case of firefox, whose bug I have explained in the bugzilla. For all other applications, the issue is in the screen reader code, as explained below > > i can reproduce the empty text buggy event with pluma, any entry in > > evince or caja, with the program launcher alt-F2 in mate desktop also. > > Do you reproduce it with the fix I mentioned? FTR: > > “ > Ksamak, on Mon 21 Nov 2016 16:00:05 +0100, wrote: > > if text and (text.caretOffset >= 0): > > offset = text.caretOffset > > if offset == text.characterCount: > > offset -= 1 > > So if the string is empty, offset becomes -1, and thus atk duly reports > this as bogus. I have added this after: > > > if offset == 0: > > offset = 0 > > > [x, y, width, height] = text.getCharacterExtents(offset, 0) > ” > > You need to fix this, otherwise passing -1 as offset will indeed always > bring you 0,0 0:0, as could be expectable for a bogus offset. _______________________________________________ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
