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.
If you click the gear icon by a block, and the tray expands to show the block configuration, it's not obvious how to collapse the try (ie. you decided not to change the block configuration). And, in fact, it's easy to misinterpret the cancel button as the button to collapse the tray, but what it actually does is throws out all previous changes made in the IPE!
Comment | File | Size | Author |
---|---|---|---|
#9 | panels-ipe-esc-focus-fixes-2636490-9.patch | 7.22 KB | samuel.mortenson |
|
Comments
Comment #2
samuel.mortensonAny icon preference from https://design.google.com/icons/ ? Also, should the tray automatically close when clicking outside of it?
Comment #3
phenaproximaMy vote would be to put a little "X" icon (distinct from the cancel button) in the top right corner of the expanded tray. Additionally, I think that the Esc key should close the tray. I don't think clicking outside the tray should close it, since working on an IPE layout may well involve a lot of clicking in and out of the tray.
Comment #4
dsnopek+1 on the Esc key closing the tray. That would be good for accessibility too!
Comment #5
samuel.mortensonHere's a first shot at this - I basically made the entire tab content area focusable (but not tab-focusable), and added a keypress handler to watch for the "esc" key and see if it was pressed while something in the tab content area was focused. A bit convoluted - but this avoids the problem of pressing escape when a WYSIWYG modal is open and having both the tabs and modal close.
I also worked to add default focus to common tab content elements, which should improve accessibility going forward. For example - you can now tab through the primary tabs, and the categories beneath the tabs. When a category is open, the first item in that category is automatically focused. Also any time a form is loaded, the first form element is automatically focused. Pretty neat! We are going to have to have a formal accessibility review at some point, but these changes all feel pretty good.
This patch doesn't add a visible button to collapse the tabs, but we can address that in another issue if anyone is interested. In a previous commit I added a confirm() call to the cancel button, which should cover cases where users accidentally click that to close the tabs.
Comment #6
Bcwald CreditAttribution: Bcwald commentedLooking good!
I reviewed this, here are a few things I found:
1) When using ESC, it doesn't remove the body class
panels-ipe-category-picker-top-open
2) When selecting an entity, on return to the form where I am going to be placing the content, the drawer does not get in focus, so ESC doesn't do anything until I click on the drawer.
3) After I select something and its ready to be placed, ESC should trigger an "are you sure you want to close" prompt. Same for in "edit mode" and I have moved an item.
Comment #7
samuel.mortensonHere's an updated patch which addresses (1), (2) is a Core issue with focus being lost after a modal is closed in a form, and (3) is fairly complicated so I'm wondering if we should make a new issue for adding better confirmations across the board (moving/removing blocks, closing forms via clicking the tab or pressing the ESC key, etc.).
Comment #8
Bcwald CreditAttribution: Bcwald commentedPatch works for 1.
Agreed on 3, it would be good to have a low-level method to call alerts. I think that will open the door for new features in the future.
Comment #9
samuel.mortensonRe-rolled to account for patch conflicts.
Comment #10
saltednutThis seems like a no-brainer. We've been using the patch for two months with no issues.
Comment #11
japerryComment #12
japerryYah, I've been using this patch for a while as well. I think we need to re-address the UX around the cancel button, but at least you don't mistakenly lose your data.
Committed.
Comment #14
mlhess CreditAttribution: mlhess as a volunteer commented