1513270 - Some images gets a spurious "invalid" ATK state attribute, leading to AT technologies to ignore them

Status: RESOLVED INVALID

(Core :: Disability Access APIs, defect, P3)

Description

[Colomban Wendling]

Attachment: imgbug.html

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0

Steps to reproduce:

Opening the attached imgbug.html file shows 2 paragraphs, each with an image.



Actual results:

The Orca screen reader only sees the second image, because the first one is exposed through AT-SPI with the `invalid` state attribute, which Orca uses to filter out buggy or dysfunctional objects.  This is quite legitimate on Orca's part, as this state should not be present in a properly behaving object.

I have no idea yet why Firefox adds the `invalid` attribute on the first image yet not on the second, the only difference is the image data which renders fine in both cases, and seem legitimate to me.  The first comes from the original site problem (dragonium.net), and the second is a Gimp-saved version of the first.


Expected results:

Both images should be recognized and vocalized by the Orca screen reader. Image data shouldn't affect this, as the alt and/or title attributes are used, and present in both cases.
The AT-SPI object shouldn't expose the `invalid` state.

Tested with FF52 and 60, but likely to affect all versions.

Comment 1

[Colomban Wendling]

Note that this does *not* depend on the use of `data:` URIs: the initial problem is visible with plain files.  I used `data:` URIs because it made it easier to submit the issue; but apparently it's caused by the image data alone.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:Jamie, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 3

[James Teh [:Jamie]]

I tried to look into this, but am struggling to quickly locate the node in Accerciser. (From what I've read in the docs, control+alt+a should select the current focus in the Accerciser tree, but that doesn't seem to work for me.)

The difference between the two images is that the first image has the "animated" state. From what I can see in the Gecko code, that should be exposed as ATK_STATE_ANIMATED. I don't see how we could be exposing that as ATK_STATE_INVALID, but as noted above, I'm having a lot of trouble testing this.

Comment 4

[Colomban Wendling]

The difference between the two images is that the first image has the "animated" state. From what I can see in the Gecko code, that should be exposed as ATK_STATE_ANIMATED. I don't see how we could be exposing that as ATK_STATE_INVALID,

Interesting info. Maybe that would simply be an incorrect of missing mapping at some level?

From what I've read in the docs, control+alt+a should select the current focus in the Accerciser tree, but that doesn't seem to work for me.

I overheard these kind of command should have been fixed very recently in accerciser, probably only in the Git for the moment.

You should also be able to add a bookmark for a particular node, it just has that annoying feature of being index-based, so it requires the same a11y tree up to the widgets (including siblings).

Comment 5

[Colomban Wendling]

Attachment: bmo1513270.py

This is still relevant as of today's Nightly build.

Is there anything else I could do to help this move forward?

I tried to look into this, but am struggling to quickly locate the node in Accerciser. (From what I've read in the docs, control+alt+a should select the current focus in the Accerciser tree, but that doesn't seem to work for me.)

This should probably be fixed by now. FWIW, for me Accerciser's object "path" for the node is "0 24 0 0 0 0 0" if I have only my test page open in Nightly.

I also attach an AT-SPI client helper that will print the states of all images in the current document upon focus changes, if that can help debugging. All one has to do to see the states is run it in a terminal, and do any focus change in the relevant Firefox window.

Comment 6

[Colomban Wendling]

This is still relevant as of today's Nightly build.

Is there anything else I could do to help this move forward?

I tried to look into this, but am struggling to quickly locate the node in Accerciser. (From what I've read in the docs, control+alt+a should select the current focus in the Accerciser tree, but that doesn't seem to work for me.)

This should probably be fixed by now. FWIW, for me Accerciser's object "path" for the node is "0 24 0 0 0 0 0" if I have only my test page open in Nightly.

I also attach an AT-SPI client that will print the states of all images in the current document upon focus changes, if that can help debugging. Al one has to do to see the states is run it in a terminal, and do any focus change in the relevant Firefox window.

Comment 7

[James Teh [:Jamie]]

Thanks much for the client; that will be hugely helpful. I'll try to look into this in the next couple of weeks; I'm occupied with other pressing work right now.

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Comment 9

[Colomban Wendling]

I just checked and this still affects 91esr and 102.0a1

Comment 10

[Colomban Wendling]

For what is worth I checked a couple of webpages I had around for images with the invalid state, and found this:

• the "donate" image on https://blog.documentfoundation.org/ (I believe in the right sidebar)
• most images/avatars on https://salsa.debian.org/ (e.g. https://salsa.debian.org/gnome-team/evince)
• https://commons.wikimedia.org/wiki/File:SE2012May20A.gif

So it seems fairly more widespread than I expected, so I gave it another look and I still couldn't find any code path that could lead to anything having STATE_INVALID.

This started me questioning the support libraries, and I finally noticed a bug in at-spi2-atk (which basically maps ATK to AT-SPI2) for the ANIMATED state indeed, which is simply not handled. I submitted a fix at https://gitlab.gnome.org/GNOME/at-spi2-atk/-/merge_requests/26; once merged it should fix this issue, which doesn't seem to be Firefox's fault in the end.

I'm gonna leave this open for the moment, but when the the at-spi2-atk issue is settled this report could be closed as INVALID or so.

Comment 11

[Alex ARNAUD]

I'm gonna leave this open for the moment, but when the the at-spi2-atk issue is settled this report could be closed as INVALID or so.

Hello Colomban,

There is an accessibility tree inside the Firefox debugging tools, could you confirm the state is correct there?

On Firefox 100 on Windows, I don't see any invalid state.

Thanks in advance.

Comment 12

[Colomban Wendling]

There is an accessibility tree inside the Firefox debugging tools, could you confirm the state is correct there?

It is, and it probably was from day 1. My initial thinking was there was something wrong with Firefox's ATK implementation, which makes it kind of irrelevant whether the internal state is correct or not. But apparently the issue was outside Firefox, and was going unnoticed for a long time because STATE_ANIMATED is very seldom used.

Now Mike merged the AT-SPI2-ATK MR I'll try the real deal and confirm it's fixed.

Comment 13

[Colomban Wendling]

I just verified upstream AT-SPI2-ATK does work fine (no surprise, but still), so I'm gonna close this.