Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Usability: Drop mask changes standard interactions of other elements on the page and causes user to click twice #1715

Closed
c4blackarrow opened this issue Sep 13, 2013 · 6 comments

Comments

@c4blackarrow
Copy link

Description:

The use of the drop mask has several major usability issues since it blocks all controls underneath.

  1. Buttons and other interactive elements do not trigger and do not appear interactive to the user. (Hover, cursor changes etc). This causes confusion for the user as they are not sure what elements can be interacted with. This may also get in the way of other necessary JavaScript events from other code.
  2. The user is now required to click twice to perform any other action. This also causes the user to feel that elements are disabled, or that the website is not accepting its clicks.

Steps:

  1. Go to the Select2 Example page
  2. Open the first Select2
  3. Hover over the navigation,github/download buttons, text links, etc.
  4. Click on Learn More On Github Button

Expected:

  1. Button displays hover effect and cursor changes
  2. Clicking on the button takes me to the URL

Actual:

  1. Button appears disabled as it has not hover effect and the default cursor is displayed.
  2. Clicking the button does nothing.
  3. User scratches head and wonders what is going on.
  4. User now sees the button is enabled, is confused, clicks and wonders why the second click worked
  5. User questions reality

All joking aside, this is a rather large usability issue because it temporarily changes how the entire site reacts to the users input. Select2 should not be modifying standard interactions that do not have anything to do with it. It is not a modal interaction and therefore should not block the UI from functioning. Additionally this is particularly annoying when there are multiple Select2's on the screen that I fill out in order, needing to click from one to the other. There is quite a bit of user frustration.

Suggestion:

Remove the mask entirely and move all close events to the document and track the event target for purposes of not closing the select2 element I just clicked on. I would love to know why the mask was ever used in the first place and what technical hurdle it was trying to address.

@ivaynberg
Copy link
Contributor

the mask is the only sure-way of making the dropdown close when the user clicks outside of it. document-level handlers are unreliable because when select2 is dropped inside a modal or popup or other things, often these things intercept clicks and do not propagate them to the document.

@c4blackarrow
Copy link
Author

Respectfully I have to disagree that this should be closed.

When comparing the two issues, the change in user experience is the bigger bug. The issues of some modals stealing the event and not allowing it to bubble to the document should be seen as a bug in that widget, not select2.

I would kindly ask why you do not see the usability issue as a problem worth investigating. If the issue you have with trusting just the document when select2 is in a modal, then provide an option to configure what element(s) should be used instead or in addition.

At the very least the use of the mask should be an option not used every time because it comes with severe drawbacks and is solving for a very specific issue, not the general usage.

Let me know what you think.

Thanks

@ivaynberg
Copy link
Contributor

the mask was a last resort measure i put in place because of a ton of bugreports i have received about the dropdown not closing when users click outside of it.

whether or not preventing clicks is correct or incorrect i will not comment on. for example, users of select2 do not want click events from inside select2 to propagate to the outside, so select2 prevents them from bubbling. perhaps similar logic applies to modals.

i am closing this because i do not see a good solution and you have not yet provided one either. when you have an idea that will work better then what we have now i will be happy to reopen the issue.

@c4blackarrow
Copy link
Author

Sorry, my understanding of opening a bug is that it can be tracked, there are quite a few people who submit fixes, by closing this you arn't allowing others to investigate.

Yes as I have time I will try to write my own solution as this bug stops me from having my org upgrade select2.

Of solutions, would you rather see this as an option to use the original closing method or mask, or would you rather a different close method be written entirely, if so eat are the bugs that caused you to add the mask.

And on a final side note, what reasons does select2 have to become an event black hole? Preventing default, sure, preventing propagation can only lead to not playing well with others. (Such as anything using event delegation because select2 isn't letting the mousedown or click to propagate (you know so a menu can close correctly))

@morungos
Copy link

morungos commented Oct 2, 2014

As a special case of this issue, I'm finding that the drop mask is actually occluding the clear button too. I'm not especially fussed about the rest of the screen, but that at least should not require two clicks to access, since its conceptually part of the same widget. My workaround is to move .select2-dropdown-open above the mask, and that seems to resolve the issue for me.

I've added this workaround in: https://github.com/ivaynberg/select2/pull/2715

@nguyenchiencong
Copy link

This is a real issue and should not be closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants