No focus change event when Shift+Tab at top of screen

VERIFIED FIXED in mozilla10

Status

()

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

People

(Reporter: Frank DiPalermo, Assigned: surkov)

Tracking

(Blocks: 2 bugs)

Trunk
mozilla10
x86
Windows 7
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; Tablet PC 2.0; MALC)
Build Identifier: Firefox 3.6.12

Open any web page.  Use Shift+Tab repeatedly until focus is on top most item in the page.  Press Shift+Tab again and note that no FocusChanged event is fired.  Therefore, screen readers do not know that focus has moved to the document.

Reproducible: Always
(Reporter)

Updated

7 years ago
Blocks: 617918

Comment 1

7 years ago
This is confirmed with NVDA, too.
Status: UNCONFIRMED → NEW
Component: Disability Access → Disability Access APIs
Ever confirmed: true
Product: Firefox → Core
QA Contact: disability.access → accessibility-apis
Summary: JAWS - No focus change event when Shift+Tab at top of screen → No focus change event when Shift+Tab at top of screen
Version: unspecified → Trunk
(Assignee)

Comment 2

7 years ago
Is it regression? How bad is this bug from user experience point?
(Reporter)

Comment 3

7 years ago
From Frank on 12/10/2010:
Yes, it is a regression.  It does not fail in FF 3.5.11.
I expect it is not a great huge deal for screen reader user, but it is confusing.
(Assignee)

Updated

7 years ago
Blocks: 375743

Updated

6 years ago
Duplicate of this bug: 644455

Comment 5

6 years ago
As noted in bug 644455, this also occurs when shift+tabbing to the top of an iframe document.
(Assignee)

Comment 6

6 years ago
Enn, do I understand right that DOM focus event is not fired for DOM document in this case because it's considered that DOM document focus state wasn't changed (it had focus when its child element was focused and it has focus when it's focused)? If this is correct then how would I catch this case to fire a11y focus event (in sense what events could I listen or what algorithm could be)?
That's correct. The document is still focused, but the content that was focused received a blur event, which you can listen for.
(Assignee)

Updated

6 years ago
Blocks: 546068
(Assignee)

Updated

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

Updated

6 years ago
Duplicate of this bug: 661623

Comment 9

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

Comment 10

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
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.