User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.4) Gecko/20100611 Firefox/3.6.4 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.4) Gecko/20100611 Firefox/3.6.4 (.NET CLR 3.5.30729) After a11y has been enabled, the information about the window drawing the caret is unavailable until the user changes focus. Since a11y is responsible to update the system caret in Mozilla based applications, it should do so already once a11y is enabled, not wait until keyboard focus has changed. Reproducible: Always Steps to Reproduce: 1. Close all instances of the Mozilla based application you want to try this in. This is to ensure a11y is disabled before we continue. 2. Start a new instance of the Mozilla based application. 3. Get the window handle in any way you like. But make sure the window and caret is visible (by design it must be visible), and not minimized. 4. Call SendMessage(hwndMozillaApp, WM_GETOBJECT, 0, OBJID_CLIENT) to force-enable a11y. 5. Call GetGUIThreadInfo(). Actual Results: Structure member hwndCaret is 0, and rcCaret is all 0. Expected Results: Valid hwndCaret and correct values in rcCaret, without having to change the focus within the Mozilla application. It's important to note that this bug makes it impossible to call AccessibleObjectFromWindow() and get OBJID_CARET object, since you need a valid hwndCaret returned from GetGUIThreadInfo() first.

David, could you look into this one?

I forgot to add how I'm affected by this: My code depends on the caret revealing it's position once any Mozilla application has started. I use the position to call AccessibleObjectFromPoint(). "All" other MS Windows applications will give me the caret window through GetGUIThreadInfo() without changing any focus. Even non-MSAA applications updates this information, like Office applications. It's crucial for us to do so, since once a11y has been enabled, we want to be able to access the object located where the caret is before any focus change. My current ugly workaround is to use SetForegroundWindow(GetDesktopWindow()) and then SetForegroundWindow(hMozillaWnd). It works in most situations in XP. It fails most of/all the time in Win7 though (haven't had time to debug to be sure).

The workaround only works in Windows XP. In Vista and Win7 when UAC is enabled, it doesn't work at all. Until this gets fixed, I'm forced to let the user click on a system modal messagebox (which steals focus), to let them know about the issue and at the same time fixes the problem.

AUTO-CLOSED. This bug untouched for over 2000 days. Please reopen if you can confirm the bug and help it progress.