Added a cool Input Field option for SweetAlert

[nutterbrand]

It is nice to have an input field for an alert to accept user input. I added the following features:

1. Added a parameter: inputField: (true | false) to enable the input field.
2. Added the necessary focus() to the input element programatically.
3. Updated the documentation to include the parameter and to include an example of a use case.

Update: I added an important fix that I missed on the first commit. That is the commit with the message: "Added fix for running params.doneFunction() without a parameter". Please include the head of master in the merge to get the latest changes.

[Unitech]

nice thank you!

[fidoboy]

When using this on mobile devices (iOS) there is a problem when the input lost focus. This can be solved by adding this code, after inputField.focus(); call:

inputField.onblur = function() {
    window.scrollTo(0, 1);
    setTimeout(function() {
        window.scrollTo(0, 0);
    }, 20);
};

also it could be nice to add a little delay to the focus() call to allow the modal fully open before displaying the onscreen keyboard.

[nutterbrand]

Thank you!
On Oct 21, 2014 5:50 PM, "fidoboy" notifications@github.com wrote:

When using this on mobile devices (iOS) there is a problem when the input
lost focus. This can be solved by adding this code, after
inputField.focus(); call:

inputField.onblur = function() {
window.scrollTo(0, 1);
setTimeout(function() {
window.scrollTo(0, 0);
}, 20);
};

also it could be nice to add a little delay to the focus() call to allow
the modal fully open before displaying the onscreen keyboard.

—
Reply to this email directly or view it on GitHub
#90 (comment).

[fidoboy]

It seems that there is another serious problem and i don't know how to avoid it. Focusing the input field immediately, when displaying the modal works fine but it's a bit ugly on mobile devices because the opening animation is lost. I've tried adding a delay to the inputField.focus() but then it doesn't work on iOS. Also, i've tried not focusing the inputField at all, leaving the user to tap the input after the dialog is opened, but this also doesn't work, cause on iOS when you tap the input field after it's opened you can't write anything. So, if there is no better ideas, the focus on open, as it's working with current code, is the best approach and the only one which works fine...

[nutterbrand]

Good to know. The current code seems ideal. I'll experiment with it on iOS.
On Oct 22, 2014 10:45 AM, "fidoboy" notifications@github.com wrote:

It seems that there is another serious problem and i don't know how to
avoid it. Focusing the input field immediately, when displaying the modal
works fine but it's a bit ugly on mobile devices because the opening
animation is lost. I've tried adding a delay to the inputField.focus() but
then it doesn't work on iOS. Also, i've tried not focusing the inputField
at all, leaving the user to tap the input after the dialog is opened, but
this also doesn't work, cause on iOS when you tap the input field after
it's opened you can't write anything. So, if there is no better ideas, the
focus on open, as it's working with current code, is the best approach and
the only one which works fine...

—
Reply to this email directly or view it on GitHub
#90 (comment).

[lologhi]

👍

[hszcg]

@t4t5 just wondering that do you have any plan to merge this feature?

I personally like it very much :)

[jpeet]

+1 It would be very useful for us too

[elahmo]

+1 for this, this would be amazing and nice way to avoid many, compared to this, complex modal windows when all is needed is a simple text box.

[atwellpub]

+1

am working to implement this in a project and want to include placeholder like:

inputField: {
   placeholer: 'sometext' 
}

Added a working example:

https://gist.github.com/atwellpub/1a3bbd9e6232542d219b

[timcosta]

+1 on this feature.

[t4t5]

Due to popular demand, I have actively started looking into integrating this in a future release. I want to make some changes though so you're going to have to wait just a little longer. Just letting you guys know. Thanks so much for the contributions! :)

[craigsheen]

+1

[Pezmc]

@t4t5 is there anything we can do to help with integrating this feature?

[soundarapandian]

👍

[jprichardson]

I want to make some changes though so you're going to have to wait just a little longer.

@t4t5 Which changes were you going to make? [Anxiously awaiting this :)]

[t4t5]

Alright, we're very close now! I have pushed a branch called "input-field" (57283d9) but would need some help with testing and bug fixing.
If you hit "enter" in the current implementation, the modal will disappear regardless of what the value of "closeOnEnter" is. It's probably an easy fix, but I am a bit tired. :)

Also, the code is starting to get a little messy so we should probably start cleaning it up soon so that it doesn't become a pain to work with.

[miguelsvq]

About the closeOnEnter bug you are resolving: Enter and space will make $targetElement = $okButton (Lines 448+), since the btnIndex of your form element is -1. To be modal the "focusable" elements list is reduced to the two buttons (� �$modalButtons = modal.querySelectorAll('buttons[tabindex]') ) and the focus/blur implementation is going to make it funny... you can't make form elements get focus (because the onBlur implementation). If focus is in an element not in this buttons list the Enter key makes OK button $targetElement (L448+) and the click event is send (L463+).
I'm building forms inside swal windows and I'm dealing with it. What I did is to make the querySelectorAll not 'button[tabindex]', but '[tabindex]', and gave from elements a tabindex value. This way those element become focusable & tabbable, you can navigate those controls using tab keys and get the default browser behaviour to check/uncheck with spacebar, can use carriage returns inside textareas, etc.
That change in the code seems minimal to me and I've not found any undesirable side effect yet.

[lvillani]

@t4t5 I added the ability to specify a default value when first opening the prompt in this commit: https://github.com/lvillani/sweetalert/commit/8e62aa724f8a67ff07dca1eb6064c8289d226d43

[waldyrious]

With the closing of #5, shouldn't this PR be closed too?

[t4t5]

Indeed, the wait has been long, but this is is finally fixed! Download the latest release (v0.5.0) and check out the last part of the SweetAlert tutorial to learn how to use the input field!

Thanks for the suggestion guys. Keep it sweet!