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

[Samuel Thibault <samuel thibault ens-lyon org>]

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.