Problem/Motivation
There is an issue with the focus and scroll behaviour for existing nodes with the maximum number of allowed items, because the 'Add media' button - which has the correct logic and behaviour - is not present on the form.
By default, if the node edit form has a media library widget that has max values, the form focuses on and scrolls to the media item when loaded. I believe this is caused by the intentional adding of focus to the item when the modal is closed. So when creating a new node, this flow works correctly:
- Navigate to the 'Add media' button and click
- Choose a media item
- Click 'Insert selected'
- Focus is set to the item as expected and you can continue navigating through the form
But this breaks the form for existing nodes with the max values, where there is no button, because on loading the form, the focus is set to the media item.
Proposed resolution
Only add the 'focus and then disable' behaviour for media library opener buttons if the widget is being built as a result of updating the selection. So that if the widget is being built on page load, the focus code doesn't run. See #15 for details.
Remaining tasks
Create a patch to ensure that:
When editing an existing node with a media library widget that has the maximum allowed values, ensure focus starts at the top of the form by defaultWhen the media library widget modal is opened and closed, keep focus on the media library widget or selected item- Reviews
Screencast before patch - focus jumps to media library on load: https://www.screencast.com/t/oeoGznWclEA1
Screencast after patch - focus stays at the top of the page as expected on load: https://www.screencast.com/t/DCRDNamfA
Screencast showing focus works as expected when selecting from the media library widget: https://www.screencast.com/t/nCle4Sonam
User interface changes
None
API changes
None.
Data model changes
None.
Comment | File | Size | Author |
---|---|---|---|
#20 | 3089745-media-library-focus-20.patch | 5.33 KB | larowlan |
#20 | 3089745-media-library-focus-20-fail.patch | 3.83 KB | larowlan |
#18 | interdiff.3089745.17-18.txt | 1.05 KB | aleevas |
#18 | 3089745-9.1-18.patch | 3.1 KB | aleevas |
#18 | 3089745-8.9-18.patch | 2.81 KB | aleevas |
Comments
Comment #2
seycom CreditAttribution: seycom commentedComment #3
seanBClosed #3091297: Node edit form with media library widget defaults focus to media field if it has a value as a duplicate.
Comment #4
pameeela CreditAttribution: pameeela commentedPatch works as advertised, thank you! This has been driving me nuts :)
Comment #5
pameeela CreditAttribution: pameeela commentedComment #6
pameeela CreditAttribution: pameeela commentedTests are green and this passed manual testing so marking RTBC.
Comment #7
xjmNice find! Thanks. This should help make the stable Media Library more usable while also still retaining our accessibility commitment.
We need the transpiled ES5 JS in the patch too for this to be committable. Here's a reference on the transpilation: https://www.drupal.org/node/2815083
Comment #8
pameeela CreditAttribution: pameeela commentedUpdated patch attached with the transpiled ES5 JS.
Comment #9
pameeela CreditAttribution: pameeela commentedComment #10
xjmWe probably need accessibility signoff for this change once we've finalized it.
Comment #11
pameeela CreditAttribution: pameeela commentedMarking this needs work because it changes the focus behaviour as well.
Without the patch, the form focuses on and scrolls to the media library widget when loaded (which is the wrong behaviour). But it also allows focus on the media library widget when the modal is closed (which is the desired behaviour).
With the patch, the form does not focus on or scroll to the media library widget when loaded (which is the desired behaviour). But it also loses focus on the media library widget when the modal is closed - focus returns to the top of the page (which is the wrong behaviour).
So we need a patch that both:
Comment #12
rooby CreditAttribution: rooby commentedThe original code has no comment that describes what it's actually for, but from what I can gather it seems questionable and I don't think that just ditching the scroll is the fix here.
@pameela, you mention "Sets focus to the media library widget when the modal is open". Do you mean when the user closes the modal it should then set focus back to the library widget?
Is my understanding of what should happen correct?:
1. When a user closes the modal, if the open button gets the data-disabled-focus="true" attribute (because you can't add anymore items?) then the button should be disabled, but should also get focus.
2. When the page originally loads, no focusing on the media widget should happen at all, but if the data-disabled-focus is on, then the button should be disabled.
In that case, we shouldn't be calling the focus function at all during page load, only when the user returns from a modal.
Is there a way to act on the modal close event instead of blindly acting every time the behavior fires?
I'm also not sure about the fact we're setting the focus back to that button in the case that it is disabled because you can't add more things.
It doesn't sound too bad usiong the osx screen reader but I find it a little confusing.
I wonder if it would be better to set the focus to the item that was just added instead of to the button, although the only place to set the focus would be on the remove button of the item?
Note sure if there's somewhere better would could set the focus that would make more sense to the user.
Comment #13
joey-santiago CreditAttribution: joey-santiago at Trimble Solutions Corporation commentedWould this be good?
I'm trying to set focus and so scroll to the element when the modal window is closed only.
I think it is really rudimental, but i haven't found (yet) a way to kind of track the element where the popup was originally opened, so that the focus and scroll would go back there.
Comment #14
pameeela CreditAttribution: pameeela commentedSorry for the delay, was in the throes of conference organising and then offline for a few days.
I have updated the issue summary. @rooby, your questions led me to realise the problem was with the missing button!
Does this make more sense?
Comment #15
seanBIn
MediaLibraryWidget
we have this:We might want to check
$form_state->getTriggeringElement()
before we add thedata-disabled-focus
attribute. We only want to trigger the refocus when a user selected something in the library. The triggering element should be themedia_library_update_widget
button.I think this might be the best way to fix this.
Comment #16
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer commentedComment #17
dipakmdhrm CreditAttribution: dipakmdhrm as a volunteer and at QED42 for Drupal India Association commentedWhile someone builds a solution based on #15, here's a patch fixing the errors in the patch in #13.
Comment #18
aleevasAdded patches for latest versions
Comment #20
larowlanNew approach per #15
No interdiff, as its a brand-new approach.
Comment #21
larowlanWorked on this for bug smash.
Removing accessibility review tag, because we're not changing anything w.r.t the media library functions here, just the default state
Comment #23
larowlanFail was in HEAD
Comment #24
larowlanWe need to update the IS to indicate #15 is the proposed resolution
Comment #25
xaqroxJust reporting that #20 still applies to 8.9.2, in case anyone needs this for D8.
Comment #26
larowlanUpdated IS and removed the original report at it was conflicting. Revision history will keep it if we ever need it.
Comment #27
pameeela CreditAttribution: pameeela commentedThanks @larowlan, works as advertised. Screenshots don't really tell you anything so I've done some screencasts of before and after.
Screencast before patch - focus jumps to media library on load: https://www.screencast.com/t/oeoGznWclEA1
Screencast after patch - focus stays at the top of the page as expected on load: https://www.screencast.com/t/DCRDNamfA
Screencast showing focus works as expected when selecting from the media library widget: https://www.screencast.com/t/nCle4Sonam
Just needs a code review.
Comment #28
pameeela CreditAttribution: pameeela commentedAdded screencasts to IS and removed the screenshot as it wasn't really helping :)
Comment #29
jibranThe fix looks good to me. Just one suggestion which is not a deal breaker IMO.
This can be $this->assertNotNull($open_button->getAttribute('disabled'));
Let's add a comment here explaining what we are trying to determine.
Ignore this there is a comment already.Comment #30
alexpottCommitted and pushed fb46d2747f to 9.1.x and 6096fe17dc to 9.0.x and b409e09e92 to 8.9.x. Thanks!
I agree with @larowlan that this fix doesn't adjust the accessibility features of the media library so removing the needs accessibility maintainer review seems fine.
It's great that the code now matches the code comment :)
The code in HEAD was not accounting for the
When the user returns from the modal
part of the comment.Removed unused use on commit.
Comment #35
idebr CreditAttribution: idebr at iO commented