Skip to content
This repository has been archived by the owner on May 29, 2019. It is now read-only.

v0.7 problem with typehead + ng-submit + Enter #1298

Closed
xiehan opened this issue Nov 25, 2013 · 8 comments
Closed

v0.7 problem with typehead + ng-submit + Enter #1298

xiehan opened this issue Nov 25, 2013 · 8 comments

Comments

@xiehan
Copy link

xiehan commented Nov 25, 2013

Hi:

We're currently using the typeahead in conjunction with ng-submit on a form for inputting tags for content. We're using ng-submit because in addition to allowing us to use a regular submit button, it also allowed us to submit the form by pressing Enter, which we consider to be essential since adding tags tends to be a very repetitive operation.

I can see that as per commit 253c49f in the new v0.7.0 this is no longer possible. Other than forking the repo and removing the change which might introduce problems later on, it possible to undo this or get around it so we can use Enter again? This is pretty critical functionality for us, and we never had any problems with the implementation in the old version...

@pkozlowski-opensource
Copy link
Member

@xiehan I hear what you say... and I'm divided here. Let's some more members of the community to weight here. But I can surely consider rolling but this commit if more people are against this change (and honestly, the more I think about it I'm more against it myself :-))

@xiehan
Copy link
Author

xiehan commented Nov 26, 2013

Got it. Thanks for the consideration. I can hold off on upgrading anyway, since the v0.7.0 release doesn't seem to make much of a difference in our implementation.

I just wanted to add that I think that anything that utilizes either event.preventDefault() or event.stopPropagation() is problematic because once it's there it's very difficult to work around; my approach in my own code is to never use those in any default configuration unless I absolutely have to.

@chrisirhc
Copy link
Contributor

Just want to weigh in here. My opinion is that typeahead shouldn't modify any behavior of the input field when the dropdown isn't showing. As such, I think it should only prevent submission only if there are options showing.

If this is change is reverted, we can provide a snippet in the Wiki (or somewhere) for those who want to prevent default on enter. Just a simple directive that does preventDefault on keyCode 13 on the keydown event.

@Jarlakxen
Copy link

I have a similar issue, if i use the typehead in conjunction with ui-keypress. When type something and press enter, the ui-keypress never gets the enter.

@tomcfoglio
Copy link

I also use the typeahead + ng-submit on several inputs on my system and the submit on ENTER is critical to me.

So in my opinion the ENTER key should be allowed since it is a default behavior and the users are used to it.

@pkozlowski-opensource
Copy link
Member

OK, I think that there is enough weight to remove this commit and this is what I'm going to do.

@troch
Copy link

troch commented Dec 5, 2013

@pkozlowski-opensource I was going to post an issue about this, because it is not great in my working scenario: I have a search form using ng-submit like @xiehan, with typeahead giving suggestions. I would like the user to be able to send his/her raw search by pressing enter, when no matches are found or no match is selected.
Right now, the code prevents default event on enter keypress when no matches are found.
However, before reverting, different scenari need to considered:

  • Is it needed to introduce a new directive typeahead-prevent-submission?
  • Would you prevent submission only if typeahead-editable is set to false?
  • etc...

Imo I would go for a custom directive, default to false, which would prevent submission or not.

It also brings me to another discussion: when matches are found, the first item is automatically set to active. Pressing enter selects this first item and doesn't send the form (if inside a form). My average user wouldn't think about escaping typeahead before pressing enter. I think a new directive typeahead-select-first (default to true) would be beneficial. Should I create an issue for this?

Edit: I found issue #908

@alonisser
Copy link

👍

Just want to weigh in here. My opinion is that typeahead shouldn't modify any behavior of the input field >when the dropdown isn't showing. As such, I think it should only prevent submission only if there are options >showing.

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

No branches or pull requests

7 participants