Last Comment Bug 618046 - No focus change event when Shift+Tab at top of screen
: No focus change event when Shift+Tab at top of screen
Status: VERIFIED FIXED
:
Product: Core
Classification: Components
Component: Disability Access APIs (show other bugs)
: Trunk
: x86 Windows 7
: -- normal (vote)
: mozilla10
Assigned To: alexander :surkov
:
Mentors:
any
: 644455 661623 (view as bug list)
Depends on: 673958
Blocks: focuseventa11y jaws 546068
  Show dependency treegraph
 
Reported: 2010-12-09 12:30 PST by Frank DiPalermo
Modified: 2011-09-29 08:04 PDT (History)
9 users (show)
surkov.alexander: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Frank DiPalermo 2010-12-09 12:30:59 PST
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
Comment 1 Marco Zehe (:MarcoZ) on PTO until August 15 2010-12-10 00:03:01 PST
This is confirmed with NVDA, too.
Comment 2 alexander :surkov 2010-12-10 00:19:26 PST
Is it regression? How bad is this bug from user experience point?
Comment 3 Frank DiPalermo 2010-12-10 05:09:39 PST
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.
Comment 4 James Teh [:Jamie] 2011-06-19 17:17:27 PDT
*** Bug 644455 has been marked as a duplicate of this bug. ***
Comment 5 James Teh [:Jamie] 2011-06-19 17:21:09 PDT
As noted in bug 644455, this also occurs when shift+tabbing to the top of an iframe document.
Comment 6 alexander :surkov 2011-06-29 02:08:00 PDT
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)?
Comment 7 Neil Deakin 2011-06-29 07:30:52 PDT
That's correct. The document is still focused, but the content that was focused received a blur event, which you can listen for.
Comment 8 alexander :surkov 2011-09-16 10:11:14 PDT
*** Bug 661623 has been marked as a duplicate of this bug. ***
Comment 9 James Teh [:Jamie] 2011-09-26 18:55:54 PDT
I verified that this is fixed in the last try build for bug 673958.
Comment 10 alexander :surkov 2011-09-28 02:23:42 PDT
fixed by bug 673958
Comment 11 Marco Zehe (:MarcoZ) on PTO until August 15 2011-09-29 08:04:37 PDT
Verified fixed in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20110929 Firefox/10.0a1

Note You need to log in before you can comment on or make changes to this bug.