Attachment HelloWorld.html added by mherrmann.at on 2013-08-19 07:55
Description:
Simple Hello World HTML page

Comment 1 by jteh on 2013-08-20 05:51
I can't reproduce this here with Chrome 29.0.1522.0 canary. (That is outdated, but I just updated canary to the latest and it seems to break document accessibility completely.)

Once focused on the document, if you open the Python console with NVDA+control+z, what do you get if you type focus.treeInterceptor?

Comment 2 by mherrmann.at on 2013-08-20 08:09
I am not exactly sure what you mean by "focused on the document". I performed the following steps:

• Closed NVDA and all Chrome windows.
• Started NVDA.
• Opened HelloWorld.html using Chrome (version 28.0.1500.95 m).
• Waited until NVDA read "Hello World - Google Chrome Window".
• Wiggled the mouse a bit so that NVDA read "Hello World in body".
• Pressed NVDA+control+z.
• Typed "focus.treeInterceptor".

This again returned None. I also tried focus.devInfo. This returned:

u''", 'role: ROLE_UNKNOWN', 'states: ', 'isFocusable: False', 'hasFocus: False', 'Python object: <appModules.chrome.Document object at 0x065BEC70>', "Python class mro: (<class 'appModules.chrome.Document'>, <class 'NVDAObjects.IAccessible.IAccessible'>, <class 'NVDAObjects.window.Window'>, <class 'NVDAObjects.NVDAObject'>, <class 'baseObject.ScriptableObject'>, <class 'baseObject.AutoPropertyObject'>, <type 'object'>)", 'description: None', 'location: None', 'value: None', "appModule: <'chrome' (appName u'chrome', process ID 3868) at address 65be310>", "TextInfo: <class 'NVDAObjects.IAccessible.IA2TextTextInfo'>", 'windowHandle: 591654L', "windowClassName: u'Chrome_RenderWidgetHostHWND'", 'windowControlID: 108537344', 'windowStyle: 1442840576', 'windowThreadID: 3480', "windowText: u''", "displayText: exception: 'NoneType' object is not iterable", 'IAccessibleObject: <POINTER(IAccessible2) ptr=0x3dde6c at 6539c60>', 'IAccessibleChildID: 0', 'IAccessible event parameters: windowHandle=591654, objectID=-4, childID=0', "IAccessible accName: exception: (-2147467259, 'Unspecified error', (None, None, None, 0, None))", "IAccessible accRole: exception: (-2147467259, 'Unspecified error', (None, None, None, 0, None))", "IAccessible accState: exception: (-2147467259, 'Unspecified error', (None, None, None, 0, None))", "IAccessible accDescription: exception: (-2147467259, 'Unspecified error', (None, None, None, 0, None))", "IAccessible accValue: exception: (-2147467259, 'Unspecified error', (None, None, None, 0, None))", "IAccessible2 windowHandle: exception: (-2147467259, 'Unspecified error', (None, None, None, 0, None))", "IAccessible2 uniqueID: exception: (-2147467259, 'Unspecified error', (None, None, None, 0, None))", "IAccessible2 role: exception: (-2147467259, 'Unspecified error', (None, None, None, 0, None))", "IAccessible2 states: exception: (-2147467259, 'Unspecified error', (None, None, None, 0, None))", "IAccessible2 attributes: exception: (-2147467259, 'Unspecified error', (None, None, None, 0, None))"

Comment 3 by jteh (in reply to comment 2) on 2013-08-20 10:15
Replying to mherrmann.at:

I am not exactly sure what you mean by "focused on the document".

I mean that the document should have the keyboard focus; i.e. click in it or tab to it.

• Waited until NVDA read "Hello World - Google Chrome Window".

This suggests the document didn't have the focus. Note that tree interceptors are not created unless the document gets focus.

I also tried focus.devInfo. This returned:

["name: u''", 'role: ROLE_UNKNOWN'

This definitely isn't the document.

Comment 4 by mherrmann.at on 2013-08-20 12:06
Thank you for the clarification. What I did now was to click in the document and select the text in the HTML page. This yielded the following for focus.devInfo:

u'HelloWorld.html\t91 b\t20/08/2013 09:42\t-a--'", 'role: ROLE_LISTITEM', 'states: STATE_FOCUSABLE, STATE_SELECTABLE', 'isFocusable: True', 'hasFocus: False', 'Python object: <NVDAObjects.IAccessible.IAccessible object at 0x06655530>', "Python class mro: (<class 'NVDAObjects.IAccessible.IAccessible'>, <class 'NVDAObjects.window.Window'>, <class 'NVDAObjects.NVDAObject'>, <class 'baseObject.ScriptableObject'>, <class 'baseObject.AutoPropertyObject'>, <type 'object'>)", 'description: None', 'location: (964, 218, 954, 16)', 'value: None', "appModule: <'totalcmd' (appName u'totalcmd64', process ID 4604) at address 6475110>", "TextInfo: <class 'NVDAObjects.NVDAObjectTextInfo'>", 'windowHandle: 262842', "windowClassName: u'LCLListBox'", 'windowControlID: 98756976', 'windowStyle: 1442906459', 'windowThreadID: 2716', "windowText: u''", "displayText: u'\x00HelloWorld\x00html\x0091 b20/08/2013 09:4-a--\n'", 'IAccessibleObject: <POINTER(IAccessible) ptr=0x86186e0 at 6612da0>', 'IAccessibleChildID: 6', 'IAccessible event parameters: windowHandle=262842, objectID=-4, childID=6', "IAccessible accName: u'HelloWorld.html\t91 b\t20/08/2013 09:42\t-a--'", 'IAccessible accRole: ROLE_SYSTEM_LISTITEM', 'IAccessible accState: STATE_SYSTEM_SELECTABLE, STATE_SYSTEM_MULTISELECTABLE, STATE_SYSTEM_FOCUSABLE, STATE_SYSTEM_VALID (19922944)', 'IAccessible accDescription: None', 'IAccessible accValue: None'

However, focus.treeInterceptor is still None. Only when I switch away from the Chrome window and then back to it does it get a value.

Would it help you if I tried to reproduce using Chrome canary?

Thanks!
Michael

Comment 5 by jteh on 2013-08-20 12:16
focus was pointing at totalcmd in that case. You need to press NVDA+control+z to enter the Python console once focus is in the document. NVDA+control+z is what takes a snapshot of the current state of NVDA, including the focus.

Comment 6 by mherrmann.at on 2013-08-20 14:00
I see, sorry, I did not know that. When I select the text in the HTML page and then press NVDA+control+z, I get the same output as before, ie no treeInterceptor and a ROLE_UNKNOWN object as focus object. Chrome certainly has the keyboard focus as when I press control+h, it opens the browse history. This is actually also true when I don't select any text.

I think I have managed to come up with a better example in which Chrome provably has the keyboard focus: I created another simple HTML page. It contains just a text field. This text field automatically receives the focus on opening the page using the HTML5 "autofocus" attribute. So, when you open the HTML page in the browser, you can immediately and without having to click anywhere or switch between any windows, type text into the text field.

When I repeat the above steps with the new example, which I will attach as "TextField.html", I still get None for the treeInterceptor. Similarly, focus.devInfo yields the (not very telling)

[u''", 'role: ROLE_UNKNOWN', 'states: ', 'isFocusable: False', 'hasFocus: False', 'Python object: <appModules.chrome.Document object at 0x0646B890>', "Python class mro: (<class 'appModules.chrome.Document'>, <class 'NVDAObjects.IAccessible.IAccessible'>, <class 'NVDAObjects.window.Window'>, <class 'NVDAObjects.NVDAObject'>, <class 'baseObject.ScriptableObject'>, <class 'baseObject.AutoPropertyObject'>, <type 'object'>)", 'description: None', 'location: None', 'value: None', "appModule: <'chrome' (appName u'chrome', process ID 3344) at address 653f1b0>", "TextInfo: <class 'NVDAObjects.IAccessible.IA2TextTextInfo'>", 'windowHandle: 132642L', "windowClassName: u'Chrome_RenderWidgetHostHWND'", 'windowControlID: 168572416', 'windowStyle: 1442840576', 'windowThreadID: 4980', "windowText: u''", "displayText: exception: 'NoneType' object is not iterable", 'IAccessibleObject: <POINTER(IAccessible2) ptr=0x63f24c at 653b030>', 'IAccessibleChildID: 0', 'IAccessible event parameters: windowHandle=132642, objectID=-4, childID=0', "IAccessible accName: exception: (-2147467259, 'Unspecified error', (None, None, None, 0, None))", "IAccessible accRole: exception: (-2147467259, 'Unspecified error', (None, None, None, 0, None))", "IAccessible accState: exception: (-2147467259, 'Unspecified error', (None, None, None, 0, None))", "IAccessible accDescription: exception: (-2147467259, 'Unspecified error', (None, None, None, 0, None))", "IAccessible accValue: exception: (-2147467259, 'Unspecified error', (None, None, None, 0, None))", "IAccessible2 windowHandle: exception: (-2147467259, 'Unspecified error', (None, None, None, 0, None))", "IAccessible2 uniqueID: exception: (-2147467259, 'Unspecified error', (None, None, None, 0, None))", "IAccessible2 role: exception: (-2147467259, 'Unspecified error', (None, None, None, 0, None))", "IAccessible2 states: exception: (-2147467259, 'Unspecified error', (None, None, None, 0, None))", "IAccessible2 attributes: exception: (-2147467259, 'Unspecified error', (None, None, None, 0, None))"]("name:)

I hope I understood your question of "focus" correctly. What do you think of this new example?

Attachment TextField.html added by mherrmann.at on 2013-08-20 14:00
Description:
Sample HTML page with autofocus text field

Comment 7 by jteh on 2013-08-20 22:41
If the document or the text field definitely has focus when you press NVDA+control+z and you're seeing ROLE_UNKNOWN, this means the underlying Chrome accessible has died and we haven't been informed about the new focus yet. If that's so, this is a bug in Chrome which we can't do anything about. However, you'd also be hearing fairly useless information when you tab around Chrome.

I'm not sure what the significance of selecting text is. The simplest way to ensure focus is just to tab into the document.

Pressing control+h to open history does prove that Chrome is focused, but it doesn't prove that the document has focus.

Comment 8 by mherrmann.at on 2013-08-21 11:24
I just tried this again. I am 100% sure that the text field has focus when I press NVDA+control+z, and I do see ROLE_UNKNOWN and treeInterceptor None. However, as already mentioned before, only immediately after Chrome startup and not anymore after having switched away from and then back to the Chrome window.

I played around with tab. Like window switching, tabbing to an element inside the document defines "focus" so it no longer has ROLE_UNKNOWN and a treeInterceptor that is not None. The problem is that "focus" is wrong immediately after Chrome startup.

It appears to me that everything works fine except that Chrome does not broadcast the very first focus change event after (Chrome) startup. By tabbing, it is possible to eventually generate a focus change event for the document, however to get back to the element that had focus on Chrome startup requires completing a whole "cycle" of tabs.

I also just tested this on another machine, with exactly the same outcome. Unfortunately, I could only test with the stable release version of Chrome as I could not find the exact version you are using and as you said accessibility seems to be broken in the latest development version.

I think one example where this affects NVDA users is the following: When they open a HTML file from their hard drive in Chrome, then NVDA only reads the window title, but no information about the first (/focus) element on the HTML page. When they press TAB, NVDA reads information about the second element on the page. In order to obtain information about the first element, they need to press SHIFT+TAB.

I can also reproduce this with any static HTML page such as the Python documentation. I close all Chrome windows. Then I execute the command "chrome http://docs.python.org/2.7/contents.html" in the Windows search box in the start menu. This opens Chrome on the given URL. NVDA reads the HTML page title, but when it comes to reading the page contents, it just reads "document busy". Re-executing exactly the same command while the first Chrome window is still open then leads to NVDA reading both the page title and the first page contents. This is also reproducible on my other machine.

Is there maybe another event that NVDA could listen to in the case of Chrome to correctly set the focus object on Chrome startup?

Thanks,
Michael

Comment 9 by jteh on 2013-08-21 11:28
I misunderstood your steps to reproduce. I didn't alt+tab out of Chrome after starting it, but i was opening the document from the address bar, which meant focus would have moved. (You mentioned opening the document, but I didn't realise you meant open it from Explorer/the command line.)

There's no other event we can listen to. It's actually possible it's firing the right event but its accessibility implementation isn't yet ready to handle the request for the object. Either way, I don't see any way we can work around this.

Comment 10 by jteh (in reply to comment 8) on 2013-08-21 11:31
Replying to mherrmann.at:

NVDA reads the HTML page title, but when it comes to reading the page contents, it just reads "document busy".

That's slightly different to the unknown case. If you hit NVDA+control+z and interrogate the focus, you should see a role of document, but the busy state is set, which means we can't interact with the document (and therefore don't create a buffer). I've definitely seen this bug before.

Comment 11 by mherrmann.at (in reply to comment 10) on 2013-08-21 11:40
Replying to jteh:

That's slightly different to the unknown case. If you hit NVDA+control+z and interrogate the focus, you should see a role of document, but the busy state is set, which means we can't interact with the document (and therefore don't create a buffer). I've definitely seen this bug before.

That's interesting. So the document being busy prevents the treeInterceptor from being initialized? Maybe it's possible to wait a little for the document to become ready, and generate a focus event when it is?

Comment 12 by jteh (in reply to comment 11) on 2013-08-21 11:44
Replying to mherrmann.at:

That's interesting. So the document being busy prevents the treeInterceptor from being initialized? Maybe it's possible to wait a little for the document to become ready, and generate a focus event when it is?

If i recall correctly, the document never becomes ready until you refresh. Unfortunately, I don't have the time required to debug/hack around issues like this at the moment.

Comment 13 by mherrmann.at (in reply to comment 12) on 2013-08-23 08:12
Replying to jteh:

If i recall correctly, the document never becomes ready until you refresh. Unfortunately, I don't have the time required to debug/hack around issues like this at the moment.

I see. I will try to look into this. I don't know how far I will get given my limited experience, but we'll see!

Comment 14 by jteh on 2014-02-28 02:22
I did some testing with current versions of Chrome stable (33.0.1750.117 m) and canary (35.0.1861.0 canary).

I don't seem to have this problem with documents that automatically focus a control such as your [test case. I also ahven't seen any instances of busy documents lately. Perhaps these issues have been fixed.

However, a focus event isn't fired for a document when no control is automatically focused such as in your attachment:HelloWorld.html test case. I filed GoogleIssue:chromium:347448 for document focus issues like this.

Acording to Google Issue Chromium:347448 it appears this was fixed in May 2014. Can this issue be closed? I am not able to test this with the attachment, as it is unavailable.