665412 - Broken focus when returning to editable text field after closing a tab while focused in the Navigation toolbar

Status: VERIFIED FIXED

(Core :: Disability Access APIs, defect)

Description

[James Teh [:Jamie]]

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

Comment 1

[Marco Zehe (:MarcoZ)]

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?

Comment 2

[(no longer active)]

If you guys think this is related to the editor, please let me know...

Comment 3

[alexander :surkov (:asurkov)]

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?

Comment 4

[Neil Deakin]

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>

Comment 5

[alexander :surkov (:asurkov)]

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?

Comment 6

[James Teh [:Jamie]]

I verified that this is fixed in the last try build for bug 673958.

Comment 7

[alexander :surkov (:asurkov)]

fixed by bug 673958

Comment 8

[Marco Zehe (:MarcoZ)]

Verified fixed in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20110929 Firefox/10.0a1