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

VERIFIED FIXED in mozilla10

Status

()

Core
Disability Access APIs
VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: Jamie, Assigned: surkov)

Tracking

(Blocks: 2 bugs, {access, regression})

Other Branch
mozilla10
x86
Windows 7
access, regression
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 years ago
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

6 years ago
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?

Updated

6 years ago
Blocks: 659863
If you guys think this is related to the editor, please let me know...
(Assignee)

Comment 3

6 years ago
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?
Target Milestone: --- → mozilla7
Version: Trunk → Other Branch
(Assignee)

Updated

6 years ago
Target Milestone: mozilla7 → ---
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>
(Assignee)

Comment 5

6 years ago
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?
(Assignee)

Updated

6 years ago
Depends on: 673958
Flags: in-testsuite?
(Reporter)

Comment 6

6 years ago
I verified that this is fixed in the last try build for bug 673958.
(Assignee)

Comment 7

6 years ago
fixed by bug 673958
Assignee: nobody → surkov.alexander
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Flags: in-testsuite? → in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla10

Comment 8

6 years ago
Verified fixed in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20110929 Firefox/10.0a1
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.