Closed Bug 633899 Opened 14 years ago Closed 7 years ago

Keyboard focus gets trapped on out application frame when initially opening Add-Ons Manager

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Type:
defect
Priority:
Not set
Severity:
major
Points:
5

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
blocking2.0 --- .x+

People

(Reporter: MarcoZ, Unassigned)

Details

(Keywords: access, regression)

This is a regression from bug 563912. Keyboard focus is initially trapped on the outer application frame when opening Add-Ons manager. Only clicking somewhere with the mouse un-traps it and allows tabbing. STR: 1. Open Firefox. 2. Open Tools/Add-Ons Manager. 3. Press tab. Expected: Focus should move somewhere useful. Actual: Focus does not move at all. 4. Click with the mouse, for example into the "Search Add-Ons" textbox. 5. Press tab. Result: Now, focus moves and no longer gets trapped. Reproducible: 100% reproducible with Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110213 Firefox/4.0b12pre
Whiteboard: [rewrite][hardblocker]
Is this worse than the behaviour that bug 563912 fixed? If so, let's back it out. If not, softblocker at worst by relation to bug 563912.
Group: mozilla-corporation-confidential
blocking2.0: ? → final+
Whiteboard: [d?] → [d?][softblocker]
Indeed, up to Marco to decide which ends up being worse.
Whiteboard: [d?][softblocker] → [softblocker]
Given the choice, THIS bug is definitely worse than the other one. The other is pretty bad, but this one is a no-go.
Hold it: Something was checked in between the build quoted above and today's nightly build Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110214 Firefox/4.0b12pre. The problem is no longer reproducible for me. Closing WFM.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
Sorry for the spam, but this morning, after rebooting my >PC, I saw the bug again. And the pattern is: 1. If Firefox is started for the very first time, the bug is definitely reproducible 100% of the time. 2. If Firefox is then shutdown and relaunched (I had to shutdown due to the Flash Player 10.2 installation), the bug disappears. Reopening the bug. But be aware that it may require a reboot to actually see the bug.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Additional info: Even if it is initially working within a session, it will again break after a while of surfing. No exact STR to repro. The initial report from comment #0 still stands.
I can't reproduce this for myself, pressing tab always takes me to the search box regardless of whether I've just restarted or not. Is this still bad enough on its own to backout bug 563912? I'm not even sure how that change could have caused this tbh.
This could be a screen reader interference. Marco have you tried multiple readers? Using accprobe I don't get trapped.
Yes I have tried multiple screen readers. And I have another idea: The other days, I was running several web apps in multiple *windows*, not multiple *tabs*. Today, I've been running these in tabs exclusively, and didn't run into this issue. Try opening a new window with Ctrl+N and see if that triggers the problem for you.
I can't recreate in a new window either. Odd.
Note I'm using a recent trunk.
Still can't reproduce like that. Why is this bug moco-confidential?
Group: mozilla-corporation-confidential
If this is only sometimes reproducable is it possible it is not a regression from bug 563912 at all? If it definitely is a regression we need to answer the question now we know it isn't always reproducable, assuming we either have to live with this bug or bug 563912 which would be better?
Additional observation: Once this bug hits, focus also gets trapped on most other document frames that get loaded. So loading pages once this bug hits, mostly when loaded from another page and into a new tab or window, will trap the focus, and tabbing won't move it. One has to click inside the page to get focus moving by the tab key again. An exception is when focus is set to a textbox like on google.com. Then this bug is somehow circumvented. I never see it happening in a single window instance, it is only going to hit once a second window comes into play, opened either by "open link in new window", or by pressing Control+n or the like.
OK I wonder if we have the right regression suspect here. Dave, does extensions.css affect regular documents?
Marco, can you revert bug 563912 for your local usage today and see if this bug still crops up?
I think bug 563912 should stay in, since it does more good than bad IMO. Also, what still puzzles me is that Sunday's nightly build was the one I could most reliably reproduce it, but builds from Monday up to Wednesday are not so easy to reproduce it. There was a backout on Sunday having to do with some tabView thing that might be affecting this. I therefore vote for letting bug 563912 stay in, but watch out for this bug here on an ongoing basis.
(In reply to comment #16) > OK I wonder if we have the right regression suspect here. Dave, does > extensions.css affect regular documents? No, it only affects the add-ons manager and even then unless something very strange is going on the change there should only affect things inside richlistitems. Based on the comments here I'm going to unmark this as a regression from bug 563912 and leave that in the tree, we can always go back on that if needs be.
No longer blocks: 563912
** PRODUCT DRIVERS PLEASE NOTE ** This bug is one of 7 automatically changed from blocking2.0:final+ to blocking2.0:.x during the endgame of Firefox 4 for the following reasons: - it was marked as a soft blocking issue without a requirement for beta coverage
blocking2.0: final+ → .x+
Whiteboard: [softblocker] → [softblocker][wanted fx5]
For me, the focus moves to the search field but not to the other parts of the add-ons manager, which makes the add-ons manager unusable from keyboard. How come an accessibility regression like this fell off the tracking radar?
Hm, thought this had already been moved over to Core, given comment 15.
Component: Add-ons Manager → General
Product: Toolkit → Core
Whiteboard: [softblocker][wanted fx5]
(In reply to Henri Sivonen (:hsivonen) from comment #21) > For me, the focus moves to the search field but not to the other parts of > the add-ons manager, which makes the add-ons manager unusable from keyboard. > How come an accessibility regression like this fell off the tracking radar? Henri, do you still see this? I can no longer reproduce, Add-Ons Manager focus moves for me now. May this be a case of no visual indication of the keyboard focus? Or is this WFM?
I still see this. The focus moves between the search field and the add-on manager category tabs on the left, but I can't figure out how to move the focus to the buttons that appear on each add-on in the add-on list.
Points: --- → 5
Flags: qe-verify-
Flags: in-testsuite?
Flags: firefox-backlog+
We should address this for all in-content pages, as this also affects e.g. about:preferences and about:config. We should probably fix this in some kind of generic way. I wonder where the logic to focus the document lives and if we can teach it to find a focusable node inside the document for XUL and/or role="application" pages.
Neil, do you have time to look into this? I thought you might have thoughts / solutions considering your focus + XUL expertise.
Flags: needinfo?(enndeakin)
I don't see any issue here but if you have a log I can look: NSPR_LOG_MODULES=FocusNavigation:5,Focus:5
Flags: needinfo?(enndeakin)
This works as expected nowadays. Closing as WFM.
Status: REOPENED → RESOLVED
Closed: 14 years ago → 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.