Open Bug 1069739 Opened 9 years ago Updated 3 months ago
DIVs with overflow receiving focus, causing issues for accessibility user
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.120 Safari/537.36 Steps to reproduce: User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9) Gecko/20100101 Firefox/4.0b9 Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9) Gecko/20100101 Firefox/4.0b9 An div element with overflow-y:hidden in its style is focusable Reproducible: Always Steps to Reproduce: <html> <body> <input> <div style="overflow-y:hidden"></div> <input> </body> </html> Actual Results: div is focusable Expected Results: div should not receive focus up on tabbing Actual results: Accessibility user uses keyboard TAB key to navigate across the Web-Page. In the above case, the DIV receives the focus and nothing can be announced by Screen Readers , creating confusing and usability issue for these users. Ours is a Web Based Enterprise application and this issue is critical for us to receive 508 compliance for us Expected results: Div should not receive focus
Kaushik, This doesn't need to be security sensitive. Please don't change the priority. Leave that to the developers. You filed this under version 32 but the actual useragent values were for a beta version of Firefox 4.
Priority: P1 → --
Attachment #8492001 - Attachment mime type: text/plain → text/html
Marco, I can't reproduce this on Linux. Can you check it out?
I cannot reproduce this on Windows using Firefox 32 or 35 Nightly, with either NVDA or JAWS. Both inputs are focusable just fine and I can type in them. No problem as far as I can see.
Thanks Marco! Kaushik, it is not clear to me what build you were actually testing. If it was really Firefox 4 beta, that is far too out of date. I'm going to mark this as works for me. Please read https://developer.mozilla.org/en/Bug_writing_guidelines and if you can reproduce it with a current build, please reopen and give us detailed instructions on how to reproduce and exactly which build you were using. Thanks!
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
The Div receives the Focus in FF ESR 31.0
I have attached the sample HTML where the DIV receives the focus.
Kaushik, that attachment was only example data and did not in any way contain real information on names and salaries?
semi reduced FFDIV.html
I can reproduce the focus issue with Nightly 35 on Linux. Marco, which product/component should we put this?
Status: RESOLVED → REOPENED
Ever confirmed: true
OS: Windows 7 → All
Hardware: x86_64 → All
Resolution: WORKSFORME → ---
Version: 32 Branch → 31 Branch
Ya..the data in the table is just an example data
I still don't see the problem, or I didn't understand it. To me this looks like a contentEditable table that I can navigate with my Windows screen reader. Note that contentEditable for tables is not well defined and in general behaves badly. This is an Editor bug, IMO.
Marco, when I tab in Firefox the focus changes from the urlbar to the search input to the document and then to the table. In Chrome 37 the urlbar is focused and blurred only. I'll move this to Core Editor for triage.
Status: REOPENED → UNCONFIRMED
Component: Untriaged → Editor
Ever confirmed: false
Product: Firefox → Core
Confirming that <div style="overflow:auto"> is focusable in Firefox 37 Mac. Focus can be set by script and keyboard, however not by mouse. A simple test case can be found here: https://jsbin.com/biyapa/1/edit Chrome 42 and IE11 do not show this behavior. Note that https://bugzilla.mozilla.org/show_bug.cgi?id=626919 looks like a duplicate (or this one is, since the other issue is older).
To be clear, despite the example in the first post, this bug occurs whenever a scrollbar is present. This can be with overflow-x or simply overflow: auto. For anyone experiencing this bug, setting a normally unnecessary tabindex="-1" can disable the focusing.
This issue is still not fixed in v.45.2.0. Are there any plan to get this issue fixed in the upcoming versions? - It's not a fare idea to keep adding tabindex='-1' to every element (having overflow:auto) only for firefox browser.
(In reply to satheeshdom from comment #17) > This issue is still not fixed in v.45.2.0. Are there any plan to get this > issue fixed in the upcoming versions? > - It's not a fare idea to keep adding tabindex='-1' to every element (having > overflow:auto) only for firefox browser. I agree with satheeshdom, is this going to be fixed any time soon? Pretty big issue and it's only in Firefox.
+1. The "tabindex=-1" has the rather unpleasant side effect of making nodes click-focusable.
per comment #15's sample, this doesn't use contenteditable. Is this Core: Selection or DOM: ?
Component: Editor → Selection
Hello, This is what I've found out: When a div contains an element that is bigger (either taller or wider) than the parent and has the property overflow-x or overflow-y set to any value, then it can receive the focus. See an example below: https://codepen.io/alexcanessa/pen/JNmdgN Testing on: MacBook Pro (Retina, 15-inch, Late 2013) Firefox 53.0.2 OS 10.12.3 (Sierra)
Clearly ni on Jet as he no longer works at Mozilla.
You need to log in before you can comment on or make changes to this bug.