Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.When a user selects a new formatter the formatter select control loses focus. When selecting new formatters with JAWS 11.0.1467 and FF 3.6.10 focus is consistently moved back to the top of the Manage displays table (just before the 'show weights' link).
This means that the user has to find their place in the table again, and posibly loses context for the settings configuration form for the newly selected formatter.
Comments
Comment #1
yoroy CreditAttribution: yoroy commentedNot to put a value or priority on this, but out of interest: how many tabs/clicks does this throw people back?
Comment #2
Everett Zufelt CreditAttribution: Everett Zufelt commented@yoroy
It depends on how many fields are in your content-type. But roughly 1 + 3n, where n is the nth field in the table.
E.g. if you are on the 4th field in the table you are looking at about 13 tabs to get back to where you started.
Note, this happens when clicking the 'edit' button to edit the formatter settings as well.
Comment #3
mgiffordWhat type of URL are you on? I'm not sure what type of page this is and what action is throwing of the focus.
Comment #4
Everett Zufelt CreditAttribution: Everett Zufelt commented@mgifford
On the Manage display page for a content type.
e.g.
admin/structure/types/manage/page/display
Comment #5
mgiffordOk, I've confirmed that this is a problem for keyboard only users (least in FF). When I'm reviewing it it seems to hit the autocomplete when I edit the Format select box.
Now why is jquery being called and the table being redrawn when one of these options is selected anyways:
Default, Plain text, Trimmed, Summary or trimmed, Hidden
I'm not sure how to fix this mind you.
Comment #6
Everett Zufelt CreditAttribution: Everett Zufelt commented@mgifford
There is an ajax callback when you change formatters to get the returned value from hook_field_formatter_settings_summary(). The hook returns a summary of the settings for the formatter.
Comment #7
yched CreditAttribution: yched commentedIt's possibly a larger issue with ajax-updated forms : if the ajax-refreshed part includes the triggering element (as is the case on the "Manage display" form, the whole table is refreshed), then focus is lost - because the element is in fact a 'new' element.
No time to investigate right now, but it might be worth considering a fix on the ajax framework level...
Comment #8
mgiffordadding tags
Comment #9
Everett Zufelt CreditAttribution: Everett Zufelt commentedSo, a possible solution would be to save the id of the field with focus (can we even do this?), then replace the form, then if the id still exists in the DOM set focus back to that element.
Comment #10
yched CreditAttribution: yched commentedProblem is, if the triggering element is part of the HTML refreshed by the ajax call, the 'new' element will have a different id (e.g edit-foo--2 instead of edit-foo)
Comment #11
Everett Zufelt CreditAttribution: Everett Zufelt commentedIs there any programmatic way that we can accomplish this? It isn't critical, but it is certainly annoying and disorienting
Comment #12
sun.core CreditAttribution: sun.core commentedShould definitely be fixed at the AJAX framework level. However, that's going to be quite a challenge, since we basically need to capture the xpath from the wrapping AJAX element before performing the AJAX request, and after invoking AJAX commands, check whether we can reach the element captured in the xpath again, and if so, move focus to it.
Comment #13
rfaysubscribe
Comment #14
mgiffordBouncing this to D8 & marking it for back porting.
Comment #15
bowersox CreditAttribution: bowersox commentedEverett Zufelt just found that he could not reproduce the issue at this time. We are not sure whether it is truly fixed, but closing for now. If anyone has evidence of this problem still happening, please advise.