(In reply to Hiroyuki Ikezoe (:hiro) from comment #4)
The code in Accessible::VisibilityState looks odd to me. The function returns INVISIBLE when the target frame's visibility style value is not visible or if it's visible then we walk up the tree and see if there is an ancestor whose style is not visiblity:visible. Given that a visibility:visible element in a visibility:hidden element should be visible..
Yes, that's clearly wrong. I thought I'd filed a bug on that, but apparently not...
I think what we need to do is even if the target style is visibility:hidden we have to descend down the tree and see if there is NO visibility:visible descendants (I don't recommend this way though). Or if we don't care about the descendant's visibility, the function can just check the style data for the style frame, we don't need to walk up its ancestors.
The accessibility code checks whether a specific element is "visible", and I don't think it intends to check "is any sub-part (element) visible", so I don't think we need to walk down.
That's being said, though I didn't know that, visibility:visible element in an iframe in a visibility:hidden element is not visible at all. I confirmed that Chrome does the same behavior. The DOM tree I am testing is;
Yes, an iframe should be treated atomically with regards to visibility as I recall.
Even if we need to care about this case, as far as I can tell nsIPresShell::IsVisible() correctly reflects the invisible state, so we can just check it there.
I don't think so. There is no code that communicates this information to the presShell in the OOP-iframe. That's what this bug is about.
FWIW Accessible::VisibilityState is called by Accessible::NativeState which is called by a bunch of other functions but I think the only one we need to care about is DocAccessibleChild::RecvNativeState (possibly also Accessible::State, but I'm not sure what that's for).