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!

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dsnopek created an issue. See original summary.

samuel.mortenson’s picture

Any icon preference from https://design.google.com/icons/ ? Also, should the tray automatically close when clicking outside of it?

phenaproxima’s picture

My 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.

dsnopek’s picture

+1 on the Esc key closing the tray. That would be good for accessibility too!

samuel.mortenson’s picture

Status: Active » Needs review
FileSize
7.14 KB

Here'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.

Bcwald’s picture

Looking 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.

samuel.mortenson’s picture

Here'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.).

Bcwald’s picture

Patch 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.

samuel.mortenson’s picture

Re-rolled to account for patch conflicts.

saltednut’s picture

Status: Needs review » Reviewed & tested by the community

This seems like a no-brainer. We've been using the patch for two months with no issues.

japerry’s picture

japerry’s picture

Status: Reviewed & tested by the community » Fixed

Yah, 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.

mlhess’s picture

Issue tags: +MWDS2016

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.