Open Bug 631009 Opened 11 years ago Updated 8 years ago

GetText() should tolerate wrong end boundary.


(Core :: Disability Access APIs, defect)

Not set




(Reporter: fherrera, Unassigned)


(Blocks 1 open bug)



(1 file)

After GetText patch in bug #630001 this function returns with error when endOffset is out of text boundaries.

This is causing troubles in atk, minor troubles under at-spi1 and big troubles under at-spi2.

When text is removed, from example on the location bar, we emit text-changed::delete signal. The atk bridge then calls GetText to retrieve the removed text. As we are firing the event after the text has been changed, there are a lot of chances that this call uses a endoffset out of boundaries.

Previous GetText behaviour tolerated this wrong endoffset and returned the text until the real end resulting on the atk-bridge using the wrong text for the at-spi event.

But now, GetText is failing with NS_ERROR_INVALID_ARG. That causes at-spi2 to send the at-spi event with empty text, but at-spi2 is failing, giving a invalid signal warning and a big delay that results in, for example, when replacing selected text, text entered in the wrong order.

Notice that this wouldn't happen if we fix bug #619002 but we may want also to be safe for this.
Either this way of checking endOffset against CharacterCount() at the beginning.
It looks like the "big" troubles under at-spi2 are not related/fixed by this. Even with the patch above I get:

GLib-GObject-WARNING **: gsignal.c:3081: signal name `text_changed::delete:system' is invalid for instance `0xa967a760'

and similars and wrong order when typing in the location bar.
(In reply to comment #1)
> Created attachment 509218 [details] [diff] [review]
> patch allowing out of boundaries endOffset
> Either this way of checking endOffset against CharacterCount() at the
> beginning.

That's correct behavior for IA2. The same time I wouldn't prefer failing XPCOM method for bad arguments since it's not friendly for JS. 

Since ATK needs the method working for out of range end offset then taking into account not failing XPCOM methods concept I would expect the same behavior for XPCOM. Thus it sounds reasonable if IA2 impl will be fixed for this case.

Fernando, do you take this bug?
Blocks: getText*a11y
No longer blocks: texta11y
You need to log in before you can comment on or make changes to this bug.