675155 - [e10s] no traversal from embedded frame to child document accessible on anything but the first tab, no document content available.

Status: RESOLVED WONTFIX

(Core :: Disability Access APIs, defect)

Description

[Marco Zehe (:MarcoZ)]

With current e10s builds from mozilla-central, opening a web page on anything but the first tab will load the page, but the document accessible is not available from parent to child traversal.

STR:
1. Open an e10s build and open a page like mozilla.org in the first tab.
2. Press Ctrl+T to open a second tab, and enter another url, like google or Twitter.
3. The page loads, but there is no virtual buffer coming up in NVDA 2011.2RC1. I can inspect the hierarchy with NVDA-Key+2, 8, 4 and 6 on the number pad, and I see the chrome up to the embedded frame in this second tab, but not the doc accessible that is always the first child for this embedded frame. It claims there are no children.

Comment 1

[James Teh [:Jamie]]

While parent to child traversal is indeed required for decent object navigation and does need to be fixed, it actually isn't a requirement for NVDA to load a buffer and thereby provide access to the document. If you aren't seeing a buffer, this is probably a different bug.

Is there somewhere I can get an e10s build from mozilla-central?

Comment 2

[alexander :surkov (:asurkov)]

(In reply to comment #1)

> Is there somewhere I can get an e10s build from mozilla-central?

I filed try server build for you - http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-1c3dc8b98b69

Comment 3

[James Teh [:Jamie]]

(In reply to comment #0)
> 2. Press Ctrl+T to open a second tab, and enter another url, like google or
> Twitter.
> 3. The page loads, but there is no virtual buffer coming up in NVDA
> 2011.2RC1.
I can't reproduce this. It usually works fine for me. Occasionally, focus doesn't get fired correctly, but tabbing a few times restores focus to the new document. Marco, what do you hear after pressing enter in the location bar for the second tab?

> I can inspect the hierarchy with NVDA-Key+2, 8, 4 and 6 on the
> number pad, and I see the chrome up to the embedded frame in this second
> tab, but not the doc accessible that is always the first child for this
> embedded frame. It claims there are no children.
Confirmed. However, as noted in comment 1, this shouldn't cause the first bug you describe. This is related to bug 649720.

Btw, the fix for this is to call AccessibleObjectFromEvent(contentHwnd, OBJID_CLIENT, contentUniqueID) and return that as the child of the internal frame accessible. (You may even be able to use CHILDID_SELF instead of the content unique ID, as Gecko will always give back the root object for CHILDID_SELF.) Hopefully, COM will take care of the marshalling and this will just work.

Comment 4

[Marco Zehe (:MarcoZ)]

(In reply to comment #3)
> new document. Marco, what do you hear after pressing enter in the location
> bar for the second tab?

First, i hear NVDA re-announcing the document and focused element from the first tab, then, I hear "NetscapeDispatchWnd, unknown". And that's it.

Comment 5

[James Teh [:Jamie]]

(In reply to comment #4)
> First, i hear NVDA re-announcing the document and focused element from the
> first tab, then, I hear "NetscapeDispatchWnd, unknown". And that's it.
Ah, I've seen that before too, but it doesn't happen very often on my system. If you tab a few times, you should eventually land in the document. Can you confirm this?

This is what I meant about focus problems. I'm not sure what that "NetscapeDispatchWnd" window is, but it doesn't always show up. If i can reproduce it, I'll try to debug, but I can't reproduce it at present. When you next see it, can you please press NVDA+f1, shift+control+end, control+c and then paste the result here?

Comment 6

[Marco Zehe (:MarcoZ)]

(In reply to comment #5)
> Ah, I've seen that before too, but it doesn't happen very often on my
> system. If you tab a few times, you should eventually land in the document.
> Can you confirm this?

No, I cannot. Try as I may, 20 out of 20 times I do not get a virtual buffer at all in the second or subsequent tabs. I can tab into the document, but the buffer is never created for me.

> This is what I meant about focus problems. I'm not sure what that
> "NetscapeDispatchWnd" window is, but it doesn't always show up. If i can
> reproduce it, I'll try to debug, but I can't reproduce it at present. When
> you next see it, can you please press NVDA+f1, shift+control+end, control+c
> and then paste the result here?

Will do!

Comment 7

[James Teh [:Jamie]]

(In reply to Marco Zehe (:MarcoZ) from comment #6)
> Try as I may, 20 out of 20 times I do not get a virtual buffer
> at all in the second or subsequent tabs. I can tab into the document, but
> the buffer is never created for me.
When you say "you can tab into the document", does NVDA ever announce "document" as you tab around? Does it ever announce the name of the second document?

Comment 8

[Marco Zehe (:MarcoZ)]

No, it always announces stuff from the first document, and never turns on virtual buffer.

Comment 9

[James Teh [:Jamie]]

On IRC, Marco did manage to get the second document to work.

NetscapeDispatchWnd is the window text of the content HWND. This is reported by NVDA when it fails to get the accessible from Gecko. I'm almost certain this is due to WM_GETOBJECT failing intermittently.

I'm wondering whether this is another case of bug 599814 (which, btw, I have a nasty suspicion isn't really fixed, despite the fact that it shows up less now). Is it possible that sometimes the content process is handling IPC and therefore can't handle WM_GETOBJECT (as per bug 599814 comment #10 and later)? This would explain the seemingly intermittent behaviour.

Comment 10

[David Bolter [:davidb] (NeedInfo me for attention)]

Marco, what's the current status of this bug?