Re: AT-SPI standard's management of text objects



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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]