STR: 1. With NVDA running, focus on the "Reply" button above this description. 2. Hit Enter or Space. Result: Text is inserted into the "Additional comments" field, and focus is set to it. NVDA indicates the focus change by letting the typing sound be heard. 4. Try to navigate up and down, left or right. Expected: NVDA should read the lines or characters moved to. Actual: NVDA will say "blank". Other places I've observed this is on Yammer, when hitting the "Reply" link for any message. There, a textarea is un-hidden, and focus set to it. Typed text cannot be re-read. Workaround: Tab to the next item, then shift-tab back again. This time, NVDA gets all the text info. This is a real annoyance for users since it means they have to take extra steps to be able to read text in certain situations. Other browser/AT combos like Safari+VoiceOver do not exhibit this behavior.

CC+ Ehsan in case he has an instant hunch.

Hmm, no sorry, this needs to be debugged.

Marco, I can't seem to recreate (I tried the Bugzilla STR). I'm using a debug build of trunk and an embarassingly old NVDA 2011.3rc1 with speech viewer set.

Couldn't recreate with nvda 2012.2.1 either.

(In reply to David Bolter [:davidb] from comment #4) > Couldn't recreate with nvda 2012.2.1 either. I'll have to check something. I definitely see it with a braille display attached to NVDA. Don't know if there is a way to simulate a braille display, similar to the speech viewer, too. But that may be a factor here, too. I will try to repro it without a braille display as well.

I can't reproduce this with latest Firefox and NVDA dev builds, whether with or without a Braille display. Marco, when this happens, can you please provide the NVDA object dev info from NVDA+f1?

I managed to reproduce this on Yammer just now. This was one case where the edit field got unhidden by activating a certain link, and focus got set to it. In this case, NVDA thought the focus was on a frame. The info is as follows: INFO - nvda (10:26:00): Starting NVDA INFO - core.main (10:26:00): Config dir: C:\Users\Marco\AppData\Roaming\nvda INFO - core.main (10:26:00): NVDA version 2012.2.1 INFO - core.main (10:26:00): Using Windows version sys.getwindowsversion(major=6, minor=1, build=7601, platform=2, service_pack='Service Pack 1') INFO - core.main (10:26:00): Using Python version 2.7.3 (default, Apr 10 2012, 23:31:26) [MSC v.1500 32 bit (Intel)] INFO - core.main (10:26:00): Using comtypes version 0.6.2 INFO - ......Users.Marco.AppData.Roaming.nvda.addons.vocalizer-driver.synthDrivers.vocalizer.SynthDriver.__init__ (10:26:03): Vocalizer info: Nuance Vocalizer 5.5, driver version 1.2.2, licensed:C:\Users\Marco\AppData\Roaming\nvda\vocalizer_license.ini INFO - synthDriverHandler.setSynth (10:26:04): Loaded synthDriver vocalizer INFO - core.main (10:26:04): Using wx version 2.8.12.1 (msw-unicode) INFO - braille.initialize (10:26:04): Using liblouis version 2.4.1 INFO - braille.BrailleHandler.setDisplayByName (10:26:05): Loaded braille display driver handyTech, current display has 0 cells. WARNING - core.main (10:26:05): Java Access Bridge not available INFO - core.main (10:26:05): NVDA initialized INFO - braille.BrailleHandler.setDisplayByName (10:42:19): Loaded braille display driver handyTech, current display has 88 cells. INFO - braille.BrailleHandler.setDisplayByName (11:04:37): Loaded braille display driver noBraille, current display has 0 cells. INFO - globalCommands.GlobalCommands.script_navigatorObject_devInfo (15:02:39): Developer info for navigator object: name: None role: ROLE_FRAME states: Python object: <NVDAObjects.IAccessible.mozilla.Mozilla object at 0x06152410> Python class mro: (<class 'NVDAObjects.IAccessible.mozilla.Mozilla'>, <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: <'firefox' (appName u'firefox', process ID 2804) at address 608ecb0> TextInfo: <class 'NVDAObjects.IAccessible.IA2TextTextInfo'> windowHandle: 393732L windowClassName: u'MozillaWindowClass' windowControlID: 0 windowStyle: 399441920 windowThreadID: 584 windowText: u'Yammer : My Feed - Nightly' IAccessibleObject: <POINTER(IAccessible2) ptr=0x553bd4 at 622c530> IAccessibleChildID: -349458688 IAccessible event parameters: windowHandle=393732, objectID=-4, childID=-349458688 IAccessible accRole: exception: (-2147024809, 'The parameter is incorrect.', (None, None, None, 0, None)) IAccessible accState: exception: (-2147024809, 'The parameter is incorrect.', (None, None, None, 0, None)) When K returned from this viewer, focus landed correctly on the multi-line edit field, with everything in working order. Note that all I did was hit NVDA+F1. The STR for Bugzilla, where I don't seem to be able to repro it always, either, are less likely to cause it, although I've definitely seen it happen here, too. Another spot where you might be able to reproduce this is in Facebook, where you have to hit the "Status" link on your home page which will un-hide the edit field and then set focus to it. But since I no longer have a Facebook account, I cannot confirm that.

And even on Yammer, it gives different results with each STR. A second one looked like this: INFO - globalCommands.GlobalCommands.script_navigatorObject_devInfo (15:10:04): Developer info for navigator object: name: None role: ROLE_EDITABLETEXT states: STATE_FOCUSABLE, STATE_EDITABLE, STATE_FOCUSED, STATE_MULTILINE Python object: <NVDAObjects.Dynamic_EditableTextWithAutoSelectDetectionMozillaIAccessible object at 0x0631EA10> Python class mro: (<class 'NVDAObjects.Dynamic_EditableTextWithAutoSelectDetectionMozillaIAccessible'>, <class 'NVDAObjects.behaviors.EditableTextWithAutoSelectDetection'>, <class 'NVDAObjects.behaviors.EditableText'>, <class 'editableText.EditableText'>, <class 'NVDAObjects.IAccessible.mozilla.Mozilla'>, <class 'NVDAObjects.IAccessible.IAccessible'>, <class 'NVDAObjects.window.Window'>, <class 'NVDAObjects.NVDAObject'>, <class 'baseObject.ScriptableObject'>, <class 'baseObject.AutoPropertyObject'>, <type 'object'>) description: u'' location: (268, 542, 421, 48) value: None appModule: <'firefox' (appName u'firefox', process ID 2804) at address 608ecb0> TextInfo: <class 'NVDAObjects.IAccessible.IA2TextTextInfo'> windowHandle: 393732L windowClassName: u'MozillaWindowClass' windowControlID: 0 windowStyle: 399441920 windowThreadID: 584 windowText: u'Yammer : View Conversation - Nightly' IAccessibleObject: <POINTER(IAccessible2) ptr=0x5a58e4 at 631fc10> IAccessibleChildID: 0 IAccessible event parameters: windowHandle=393732, objectID=-4, childID=-181354240 IAccessible accRole: ROLE_SYSTEM_TEXT IAccessible accState: STATE_SYSTEM_FOCUSED, STATE_SYSTEM_FOCUSABLE, STATE_SYSTEM_VALID (1048580)

In the second Yammer case, editing text should have worked correctly. This is the normal log output I would expect. I've definitely seen Firefox throw focus on to a weird "frame" object in other cases as well, though not this particular one. Unfortunately, it's incredibly difficult to reproduce reliably. I'll see what I can manage.

I can't come up with a small test case to reproduce this. However, I can reproduce it reliably on twitter.com. Str: 1. Sign in to twitter.com. 2. Go to http://twitter.com/jcsteh 3. Activate the Reply link on any tweet. Note that it only occurs the first time you activate the Reply link for any given tweet. If you do it again on the same tweet, it doesn't occur. I investigated this and my findings are rather interesting. First, here are the out-of-context (asynchronous) focus events from AccProbe in chronological order. This is how NVDA sees it. 1. I focus on the Reply link: EVENT_OBJECT_FOCUS Event Time: 20:15:30:994, Accessible Name: Reply, Accessible Role: link, Accessible State: [focusable, selectable, opaque, focused, linked], Event Data: hwnd=DC0140 ;objectId=-4; childId=-265275008; threadId=5032; windowClass=Mozill 2. I activate it. Now, I get this: EVENT_OBJECT_FOCUS Event Time: 20:15:34:348, Accessible Role: frame, Accessible State: [opaque, normal, active], Event Data: hwnd=DC0140 ;objectId=-4; childId=-216105088; threadId=5032; windowClass=Mozill 3. I alt+tab out and back in to restore the focus. 3.1. First, we get the top level window: EVENT_OBJECT_FOCUS Event Time: 20:16:00:821, Accessible Name: James Teh (jcsteh) on Twitter - Nightly, Accessible Role: frame, Accessible State: [focusable, readOnly, opaque, moveable, active, sizeable], Event Data: hwnd=DC0140 ;objectId=-4; childId=0; threadId=5032; windowClass=MozillaWindowCl 3.2. Now, we get the textarea that was supposed to receive focus in (2): EVENT_OBJECT_FOCUS Event Time: 20:16:00:899, Accessible Name: Tweet text, Accessible Role: text, Accessible State: [focusable, selectable, multiLine, opaque, focused, editable], Event Data: hwnd=DC0140 ;objectId=-4; childId=-218528128; threadId=5032; windowClass=Mozill Note that the child ids in (2) and (3.2) are different. (3.2) is the correct accessible which we should have seen in (2). I discovered that the reason we get a role of frame is that when AccessibleObjectFromEvent is called, accChild fails (most likely because it's an invalid id), so we end up with the root object, on which IAccessible2::role returns IA2_ROLE_FRAME. When I did the same with in-context event monitoring (which is synchronous), I discovered that in (2), focus does actually hit a textarea. However, in (3.2), it of course hits a textarea with a different id: 1. EVENT_OBJECT_FOCUS Event Time: 20:27:09:343, Accessible Name: Reply, Accessible Role: link, Accessible State: [focusable, focused, linked], Event Data: hwnd=DC0140; objectId=-4; childId=-338504448; threadId=5032; windowClass=Mozill 2. EVENT_OBJECT_FOCUS Event Time: 20:27:12:869, Accessible Name: Tweet text, Accessible Role: text, Accessible State: [focusable, focused], Event Data: hwnd=DC0140; objectId=-4; childId=-181415424; threadId=5032; windowClass=Mozill 3.1. EVENT_OBJECT_FOCUS Event Time: 20:27:29:592, Accessible Name: James Teh (jcsteh) on Twitter - Nightly, Accessible Role: frame, Accessible State: [focusable, readOnly, moveable, sizeable], Event Data: hwnd=DC0140; objectId=-4; childId=0; threadId=5032; windowClass=MozillaWindowCl 3.2. EVENT_OBJECT_FOCUS Event Time: 20:27:29:686, Accessible Name: Tweet text, Accessible Role: text, Accessible State: [focusable, focused], Event Data: hwnd=DC0140; objectId=-4; childId=-183833472; threadId=5032; windowClass=Mozill I suspect the difference we're seeing out-of-context is because we don't get a chance to fetch the object in (2) before it dies. So, I conclude that the textarea is for some reason changing its id (and probably creating a new accessible) after it gets focused, but a focus event isn't fired for this new id. The question is why. :)

This accessible mutation behaviour reminds me of bug 659886, though I'm not certain whether it is related. So far, I've been unable to reproduce this exactly using this method of causing accessible mutation. However, this test case does cause weird behaviour in that the focus event is never fired at all, even though the focus definitely moves. Again, I'm not sure if this is related or a different issue (as I haven't managed to trace what twitter.com is doing), but thought I'd post it in case it helps.

I still see this in Firefox 25 nightly.

A candidate fix is bug 889512

Can you please retry it?

(In reply to alexander :surkov from comment #14) > Can you please retry it? I can no longer reproduce it. It indeed got fixed in some recent cycle, it would appear.