AT-SPI SHOWING and VISIBLE issues on documents

RESOLVED FIXED

Status

()

Core
Disability Access APIs
RESOLVED FIXED
10 years ago
10 years ago

People

(Reporter: Steve Lee, Assigned: Ginn Chen)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

1.08 KB, patch
Aaron Leventhal
: review+
Mike Schroepfer
: approval1.9+
Details | Diff | Splinter Review
(Reporter)

Description

10 years ago
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.
(Reporter)

Comment 1

10 years ago
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

10 years ago
(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

10 years ago
(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

10 years ago
(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.
(Reporter)

Comment 5

10 years ago
(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

10 years ago
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.
(Reporter)

Comment 7

10 years ago
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

10 years ago
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

10 years ago
> 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.
(Reporter)

Comment 10

10 years ago
(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).

(Reporter)

Comment 11

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

Updated

10 years ago
Assignee: aaronleventhal → Evan.Yan
(Assignee)

Comment 12

10 years ago
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)

(Assignee)

Comment 13

10 years ago
It is same on Windows.

"document" doesn't have offscreen state.
OS: Linux → All
(Reporter)

Comment 14

10 years ago
(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
(Assignee)

Comment 15

10 years ago
Created attachment 301473 [details] [diff] [review]
simple patch
Assignee: Evan.Yan → ginn.chen
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #301473 - Flags: review?(aaronleventhal)

Updated

10 years ago
Attachment #301473 - Flags: review?(aaronleventhal) → review+

Updated

10 years ago
Attachment #301473 - Flags: approval1.9?

Updated

10 years ago
Attachment #301473 - Flags: approval1.9? → approval1.9+
(Reporter)

Comment 16

10 years ago
Looks good in https://build.mozilla.org/tryserver-builds/2008-02-06_14:05-aaronleventhal@moonset.net-PostBeta3A11yFixesTake2/

Comment 17

10 years ago
checked in
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.