AccessibleEditableText_setTextContents not working

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

AccessibleEditableText_setTextContents not working

Sam-142
Greetings,

I'm working with the at-spi accessibility interface on Ubuntu 8.0.4.
When we look at Firefox 3.0.1 through the at-spi interface, the main
address bar, where a user types the URL of a browse destination,
doesn't seem to work quite right.  at-spi reports that the box has
role "entry" and 4 interfaces:

1. Action
2. Component
3. EditableText
4. Text

When we apply the AccessibleEditableText interface, in particular the
routine AccessibleEditableText_setTextContents, the text in the box is
cleared, but the new text is not put into place.  We get the same
result if we do it in two steps:

1. AccessibleEditableText_deleteText
2. AccessibleEditableText_insertText

The insertText step claims it succeeded, but the address bar is empty
on the screen and when our code retrieves text from the interface, it
is empty.

On the other hand, if we insert text into the address bar when it
already has text in it, that works.

I've seen some docs on the internet that claim that firefox's
implementation of EditableText is complete (https://
developer.mozilla.org/en/Accessibility/AT-SPI_Support), so is this
behavior with the address bar a bug?

-Sam
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: AccessibleEditableText_setTextContents not working

Nagappan
Hi Sam,

This was working earlier, as part of Mozilla Google SOC '07,  we did
automation [1] based on LDTP for FF 3.x beta, but its broken with recent
updates. I remember some one pinged me in #ldtp channel about this, but I
guess we haven't logged a bug for it. The last, I verified was FF 3.0.3,
where this scenario was not working.

[1] - http://ldtp.freedesktop.org/wiki/Firefox_Test_Cases

Thanks
Nagappan

On Wed, Dec 3, 2008 at 3:48 PM, Sam <[hidden email]> wrote:

> Greetings,
>
> I'm working with the at-spi accessibility interface on Ubuntu 8.0.4.
> When we look at Firefox 3.0.1 through the at-spi interface, the main
> address bar, where a user types the URL of a browse destination,
> doesn't seem to work quite right.  at-spi reports that the box has
> role "entry" and 4 interfaces:
>
> 1. Action
> 2. Component
> 3. EditableText
> 4. Text
>
> When we apply the AccessibleEditableText interface, in particular the
> routine AccessibleEditableText_setTextContents, the text in the box is
> cleared, but the new text is not put into place.  We get the same
> result if we do it in two steps:
>
> 1. AccessibleEditableText_deleteText
> 2. AccessibleEditableText_insertText
>
> The insertText step claims it succeeded, but the address bar is empty
> on the screen and when our code retrieves text from the interface, it
> is empty.
>
> On the other hand, if we insert text into the address bar when it
> already has text in it, that works.
>
> I've seen some docs on the internet that claim that firefox's
> implementation of EditableText is complete (https://
> developer.mozilla.org/en/Accessibility/AT-SPI_Support), so is this
> behavior with the address bar a bug?
>
> -Sam
> _______________________________________________
> dev-accessibility mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-accessibility
>



--
Linux Desktop (GUI Application) Testing Project -
http://ldtp.freedesktop.org
http://nagappanal.blogspot.com
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: AccessibleEditableText_setTextContents not working

Marco Zehe-3
In reply to this post by Sam-142
Hi Sam,

On 04.12.2008 00:48, Sam wrote:

> When we apply the AccessibleEditableText interface, in particular the
> routine AccessibleEditableText_setTextContents, the text in the box is
> cleared, but the new text is not put into place.  We get the same
> result if we do it in two steps:
>
> 1. AccessibleEditableText_deleteText
> 2. AccessibleEditableText_insertText
>
> The insertText step claims it succeeded, but the address bar is empty
> on the screen and when our code retrieves text from the interface, it
> is empty.

This is already filed in this bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=452599

If you could find a regression range, or have an idea how to fix it,
assuming you're familiar with the Mozilla codebase, you're welcome to
take a stab at it and help out!

Marco
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: AccessibleEditableText_setTextContents not working

Sam-142
On Dec 4, 1:36 am, Marco Zehe <[hidden email]> wrote:
>
> This is already filed in this bug:https://bugzilla.mozilla.org/show_bug.cgi?id=452599
>
> If you could find a regression range, or have an idea how to fix it,
> assuming you're familiar with the Mozilla codebase, you're welcome to
> take a stab at it and help out!
>
> Marco

Thanks for the offer.  I'd love to help, but I am not familiar with
the Mozilla codebase.

-Sam
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

RE: AccessibleEditableText_setTextContents not working

jsp (Bugzilla)
Perhaps you could help by finding a regression range, which I think is the tedious task of figuring out approximately when Firefox stopped working as expected.  This doesn't require familiarity with the code base, just a test case, an internet connection, organization, and persistence.

On those occasions when I've done this, I've just used the nightly builds (from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/) to narrow down the time frame.  I'd start with a build from halfway between the last build that you know worked and the first build that you know didn't.  Keep splitting the time between the last working build and the first broken one and eventually you'll be able to say, "It worked on day X but not on day X + 1."  Even if you run out of time or patience before you get that far, you can give Marco the range you've narrowed it down to.  Whatever time you put in is time that someone who knows the code would otherwise have to spend on the task, when s/he could be fixing this (or some other) bug.

Maybe I'm weird, but I really like being able to say, "Here's when it broke."

-----Original Message-----
From: dev-accessibility-bounces+jsp=[hidden email] [mailto:dev-accessibility-bounces+jsp=[hidden email]] On Behalf Of Sam
Sent: Thursday, December 04, 2008 2:05 PM
To: [hidden email]
Subject: Re: AccessibleEditableText_setTextContents not working

On Dec 4, 1:36 am, Marco Zehe <[hidden email]> wrote:
>
> This is already filed in this bug:https://bugzilla.mozilla.org/show_bug.cgi?id=452599
>
> If you could find a regression range, or have an idea how to fix it,
> assuming you're familiar with the Mozilla codebase, you're welcome to
> take a stab at it and help out!
>
> Marco

Thanks for the offer.  I'd love to help, but I am not familiar with
the Mozilla codebase.

-Sam
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: AccessibleEditableText_setTextContents not working

Willie Walker
Jesse Pelton wrote:
> Maybe I'm weird, but I really like being able to say, "Here's when it broke."

You're not weird.  :-)  What I'd really like to see someone get in place
is something that does a nightly build of Mozilla and runs regression
tests of known versions of assistive technologies (e.g., Orca).  This
would help the Mozilla team determine if and when they broke something
on the Firefox/Gecko side.  Ideally, the Mozilla team would also do
regression testing *before* checking things in.

We try doing nightly builds of Firefox on the Orca side of the house,
but there are often yet-to-be-committed patches attached to other
Firefox bugs that we don't know about (e.g., a specific patch to fix a
Firefox build breakage on OpenSolaris).  As a result, we end up needing
to make the choice between being Orca developers or Mozilla build
experts.  Since we are Orca developers, we tend to lean to that side.
;-)  But, it does mean we may not see a Mozilla regression for a few
weeks.  :-(

In any case, I'll pursue the above some more to see if we can get
something going closer to the Mozilla side of the house.

Will


>
> -----Original Message-----
> From: dev-accessibility-bounces+jsp=[hidden email] [mailto:dev-accessibility-bounces+jsp=[hidden email]] On Behalf Of Sam
> Sent: Thursday, December 04, 2008 2:05 PM
> To: [hidden email]
> Subject: Re: AccessibleEditableText_setTextContents not working
>
> On Dec 4, 1:36 am, Marco Zehe <[hidden email]> wrote:
>> This is already filed in this bug:https://bugzilla.mozilla.org/show_bug.cgi?id=452599
>>
>> If you could find a regression range, or have an idea how to fix it,
>> assuming you're familiar with the Mozilla codebase, you're welcome to
>> take a stab at it and help out!
>>
>> Marco
>
> Thanks for the offer.  I'd love to help, but I am not familiar with
> the Mozilla codebase.
>
> -Sam
> _______________________________________________
> dev-accessibility mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-accessibility
> _______________________________________________
> dev-accessibility mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-accessibility

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: AccessibleEditableText_setTextContents not working

Aaron Leventhal-3
In reply to this post by jsp (Bugzilla)
Will,

Do you have some regression tests that you'd like the a11y team to use,
other than the Mochitests that they already run? The Mochitests are
built into Tinderbox now and run for every checkin.

- Aaron

On 12/4/2008 8:55 PM, Willie Walker wrote:

> Jesse Pelton wrote:
>> Maybe I'm weird, but I really like being able to say, "Here's when it
>> broke."
>
> You're not weird. :-) What I'd really like to see someone get in place
> is something that does a nightly build of Mozilla and runs regression
> tests of known versions of assistive technologies (e.g., Orca). This
> would help the Mozilla team determine if and when they broke something
> on the Firefox/Gecko side. Ideally, the Mozilla team would also do
> regression testing *before* checking things in.
>
> We try doing nightly builds of Firefox on the Orca side of the house,
> but there are often yet-to-be-committed patches attached to other
> Firefox bugs that we don't know about (e.g., a specific patch to fix a
> Firefox build breakage on OpenSolaris). As a result, we end up needing
> to make the choice between being Orca developers or Mozilla build
> experts. Since we are Orca developers, we tend to lean to that side. ;-)
> But, it does mean we may not see a Mozilla regression for a few weeks. :-(
>
> In any case, I'll pursue the above some more to see if we can get
> something going closer to the Mozilla side of the house.
>
> Will
>
>
>>
>> -----Original Message-----
>> From: dev-accessibility-bounces+jsp=[hidden email]
>> [mailto:dev-accessibility-bounces+jsp=[hidden email]] On
>> Behalf Of Sam
>> Sent: Thursday, December 04, 2008 2:05 PM
>> To: [hidden email]
>> Subject: Re: AccessibleEditableText_setTextContents not working
>>
>> On Dec 4, 1:36 am, Marco Zehe <[hidden email]> wrote:
>>> This is already filed in this
>>> bug:https://bugzilla.mozilla.org/show_bug.cgi?id=452599
>>>
>>> If you could find a regression range, or have an idea how to fix it,
>>> assuming you're familiar with the Mozilla codebase, you're welcome to
>>> take a stab at it and help out!
>>>
>>> Marco
>>
>> Thanks for the offer. I'd love to help, but I am not familiar with
>> the Mozilla codebase.
>>
>> -Sam
>> _______________________________________________
>> dev-accessibility mailing list
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-accessibility
>> _______________________________________________
>> dev-accessibility mailing list
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-accessibility
>


_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: AccessibleEditableText_setTextContents not working

Sam-142
In reply to this post by Marco Zehe-3
Hi Marco,

It appears that some other at-spi operations are affected by this
problem.  We tried using the SPI_generateKeyboardEvent to put a
character into the address box, but that did not work if the box
is empty.

Our current work around is drop into XTest and use XTestFakeKeyEvent
(http://linux.die.net/man/3/xtestfakekeyevent) to get a character
into the box.  Once a character is there we can insert/delete to get
the the exact text we want -- being careful to never let the box get
empty.

-Sam


On Dec 4, 1:36 am, Marco Zehe <[hidden email]> wrote:

> Hi Sam,
>
> On 04.12.2008 00:48, Sam wrote:
>
> > When we apply the AccessibleEditableText interface, in particular the
> > routine AccessibleEditableText_setTextContents, the text in the box is
> > cleared, but the new text is not put into place.  We get the same
> > result if we do it in two steps:
>
> > 1. AccessibleEditableText_deleteText
> > 2. AccessibleEditableText_insertText
>
> > The insertText step claims it succeeded, but the address bar is empty
> > on the screen and when our code retrieves text from the interface, it
> > is empty.
>
> This is already filed in this bug:https://bugzilla.mozilla.org/show_bug.cgi?id=452599
>
> If you could find a regression range, or have an idea how to fix it,
> assuming you're familiar with the Mozilla codebase, you're welcome to
> take a stab at it and help out!
>
> Marco

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility