Str: 1. Visit http://www.google.com/ and ensure you are focused on the search field. 2. Press control+t to open a new tab. This will move focus to the Location bar. 3. Press control+w to close the new tab. Expected: A focus event should be fired on the search field focused in step 1 and it should receive the focused state. Actual: The focus event is fired, but the focused state is not set. 4. Call IAccessibleText::caretOffset on the control which received the focus in step 3. Expected: The offset of the caret should be returned. Actual: -1 is returned. This seems to occur whenever focus returns to an editable text field resultant to closing a tab while focused in the Navigation toolbar. For example, if you open a new tab, tab to the document and then tab back to the Location bar, closing the tab still reproduces the bug. Activating and then deactivating the menu bar by pressing the alt key twice seems to resolve the problem. This did not occur in Firefox 3.6, but occurs in Firefox 4 and later. Related NVDA issue ticket: http://www.nvda-project.org/ticket/1591
I can confirm this, and it happens a lot to me when I write reports or the like. I have to shift focus somewhere else and back to the editable area to get NVDA working correctly. This is a real usability problem we should try to squash for Firefox 7. Surkov, can you take a look at this?
If you guys think this is related to the editor, please let me know...
Enn, I see the blur event on input of addressbar is fired after we receive the focus event for element in first tab. Is it not expected, right?
These are the events I see being fired: Focus page's search field: Focus: HTMLDocument Focus: Window Focus: <input> New Tab: Blur: <input> Blur: HTMLDocument Blur: Window Focus: HTMLDocument Focus: Window Blur: HTMLDocument Blur: Window Focus: XULDocument Focus: ChromeWindow Focus: addressfield Close Tab: Blur: addressfield Blur: XULDocument Blur: ChromeWindow Focus: HTMLDocument Focus: Window Focus: <input>
Got it, thank you Enn, a11y is guilty because focus and blur events are processed asynchronously in a11y and independently on each other. Sorry for confusion. Btw, do you know, how is the focus/blur events order guaranteed in the case of multiprocess Firefox?
I verified that this is fixed in the last try build for bug 673958.
fixed by bug 673958
Verified fixed in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20110929 Firefox/10.0a1