406010 - AT-SPI SHOWING and VISIBLE issues on documents

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Steve Lee]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2pre) Gecko/2007112904 Minefield/3.0b2pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2pre) Gecko/2007112904 Minefield/3.0b2pre

With multiple tabs open each document appears in AT-SPI as

+ scroll pane
  + panel
     + document frame
       + DOM objects

I notice 2 things with the STATE_VISIBLE and STATE_SHOWING

1) inactive tabs have a STATE_SHOWING on the document frame. I think
this is a bug

2) the DOM widgets in the active tab do not all have STATE_VISIBLE
although the parent objects do. I think this might be a bug or
possibly intentional for some reason I do not know.


Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Steve Lee]

Point 2) was possibly when things are not showing on the screen but I have found a couple more problems here

http://www.gnome.org/~billh/at-spi-idl/html/index.html

With the top list of links showing accerciser shows all are VISIBLE + SHOWING.
scroll so they go off screen and we find by refreshing accerciser that SHOWING goes but

Bug: object:state-changed events are NOT raised when items go off window

In fact I see no events at all when scrolling or resizing.
 
Now return the list to the screen and resize Minefield horizontally to obscure some of the links. Note we don't get a horiz scroll bar and

Bug: items keep VISIBLE when horizontally out of window

Comment 2

[alexander :surkov (:asurkov)]

(In reply to comment #0)
> 1) inactive tabs have a STATE_SHOWING on the document frame. I think
> this is a bug

If you mean ATK_ROLE_PAGE_TAB and not current tabs then why shouldn't they have state showing?

> 2) the DOM widgets in the active tab do not all have STATE_VISIBLE
> although the parent objects do. I think this might be a bug or
> possibly intentional for some reason I do not know.

At least at Gecko side they have correct visible states with me.

Comment 3

[alexander :surkov (:asurkov)]

(In reply to comment #1)
> Point 2) was possibly when things are not showing on the screen but I have
> found a couple more problems here
> 
> http://www.gnome.org/~billh/at-spi-idl/html/index.html
> 
> With the top list of links showing accerciser shows all are VISIBLE + SHOWING.
> scroll so they go off screen and we find by refreshing accerciser that SHOWING
> goes but
> 
> Bug: object:state-changed events are NOT raised when items go off window
> 

We don't fire state changed events when element visibility is changed and iirc we haven't notification from Gecko (though probably I may be wrong). In any way this should be dealt with separate bug.

> In fact I see no events at all when scrolling or resizing.

For window resizing it needs to be filed separate bug I guess

Comment 4

[alexander :surkov (:asurkov)]

(In reply to comment #1)
> Now return the list to the screen and resize Minefield horizontally to obscure
> some of the links. Note we don't get a horiz scroll bar and

for that should be filed bug and not for accessibility module I guess (though I'm not 100% sure it's a bug on gecko side)

> 
> Bug: items keep VISIBLE when horizontally out of window
> 

can you point which exactly items I can test, because it looks all of them are visible partially.

Comment 5

[Steve Lee]

(in reply to comment #2)

> If you mean ATK_ROLE_PAGE_TAB and not current tabs then why shouldn't they have
state showing?

No not the tabs themselves which I agree should be visible if they are on screen. Rather for each tab there is a tree of objects that represents the tab DOM window and only that for the current tab should have any STATE_VISIBLE as only that one is seen. I found that the document frame of all of them has STATE_VISIBLE.

The docs say 'STATE_SHOWING Indicates this object, the object's parent, the object's parent's parent, and so on, are all 'shown' to the end-user' and thsi is not true in this case.

> At least at Gecko side they have correct visible states with me.

This is weird, rather than the content reflowing when I resized the window I was getting a horiz scroll bar. I now am getting reflow so guess it was a bug in the nightly I was using. There is probably a good case for testing what happens to a page with a hscroll bar to make sure the states change and events are fired as visibility changes with scrolling.

Comment 6

[Aaron Leventhal]

Steve, is this still a bug and how does it affect Jambu?

I just opened up a second tab and looked in the first. Everything in the background tab seems to have SHOWING and VISIBLE cleared, which is correct.

Comment 7

[Steve Lee]

Hi Aaron, yes but only 1 (2 was probably those widgets outside of the viewport).
I still find the STATE_VISIBLE set on all background Document Frame's that are the grand child of the scroll panes. I've tried all sort of combinations of starting with tabs open and clicking around but always get that.

It's not a problem for Jambu (or probably anything) now as I look for Showing and Visible. 

However it is a bug as the SPI docs state VISIBLE means all parents are VISIBLE too and the parent Internal Frame is not.

Comment 8

[Aaron Leventhal]

Ah ok, so it's only on the ROLE_DOCUMENT that we have the problem?

Here's where we set it:
http://mxr.mozilla.org/seamonkey/source/accessible/src/bas/nsDocAccessible.cpp#249

Comment 9

[Aaron Leventhal]

> I still find the STATE_VISIBLE set on all background Document Frame's that are
> the grand child of the scroll panes. 

Hmm I'm seeing that VISIBLE is cleared on that object for the background tabs.

It's WORKSFORME over here.

Comment 10

[Steve Lee]

(In reply to comment #9)
> Hmm I'm seeing that VISIBLE is cleared on that object for the background tabs.
> It's WORKSFORME over here.

It seems to be Linux only (or at least not a problem on Windows).

Comment 11

[Steve Lee]

Ginn, Evan: could one of you please grab this?

Comment 12

[Ginn Chen]

My result on Linux:

Scroll pane (no visible, no showing)
  Internal frame (no visible, no showing)
    Document frame (no visible, has showing)
      Section (no visible, no showing)

Comment 13

[Ginn Chen]

It is same on Windows.

"document" doesn't have offscreen state.

Comment 14

[Steve Lee]

(In reply to comment #12)
> My result on Linux:
> 
> Scroll pane (no visible, no showing)
>   Internal frame (no visible, no showing)
>     Document frame (no visible, has showing)
>       Section (no visible, no showing)

Great Ginn. I also see it on a second Ubuntu box

Comment 15

[Ginn Chen]

Attachment: simple patch

Comment 16

[Steve Lee]

Looks good in https://build.mozilla.org/tryserver-builds/2008-02-06_14:[e-mail]-PostBeta3A11yFixesTake2/

Comment 17

[alexander :surkov (:asurkov)]

checked in