Forum Discussion
Text Entry fields not setting when control loses focus in mobile devices (Storyline 360)
We've identified that text entry fields that are added to a slide using Storyline 360 do not register if the user enters a value and then immediately clicks a Submit button when using a mobile device. In order to get the value to register, the user needs to click outside the text entry field before clicking the Submit button.
On a MAC or PC, the text entry value does register when the Submit button is clicked.
Does anyone know of any workarounds, other than to provide instructions at the start of the course?
84 Replies
Sorry about that :)
You are welcome to share privately here.
- sebastjanfCommunity Member
tnx.. Case Number: 01291937
Thanks Sebastjan!
- sebastjanfCommunity Member
any update?
- sebastjanfCommunity Member
update from my side - this error is not present in SL2 export.. seems to be 360 "feature"
Thanks for the update Sebastjan.
I took a peek at your support case and it looks like Renato has filed this as a possible bug.
I wanted to share some information on how we define bugs and how we tackle them when they occur.
I'll attach this thread as well so that we can post an update here when we can as well.
- RobertKankelborCommunity Member
Yes, this is the same bug that we are experiencing. I'll double check to see which version of Storyline 360 was used to publish the file.
Thanks Robert :)
- NejcZDCommunity Member
I can also confirm this, somewhat annoying and frustrating.
Hope you guys can fix it soon! :)
Hi Nejc,
What version of Storyline are you using?
As I mentioned above, we show that this was corrected in a previous update, so if you're still seeing it, we would certainly want to take a look.
- AlexHuntCommunity Member
I'm having this same issue as well where you have to close the browser to get the variable to set on an android device.
Clicking elsewhere or even on my Next button (which has a trigger to not go forward unless a number has been entered) won't be enough to make it "lose focus" and set the variable.
I have a ticket in for this and other reasons but I just wanted to chime in to see if the issue was still being worked on and let others know they're not alone!
Thanks for chiming in to share Alex and for letting us know that you've reached out to the support team as well.
I see that Eloisa is helping you out :)
- MatthewJevons-6Community Member
Hi All,
I have a work around for the issue above.
Add an Execute JavaScript trigger to your Submit button (before all other Submit button triggers fire) and run the following JS:
document.activeElement.blur();
This will remove the focus from the active text entry field (closing the mobile keyboard) and therefore commit the text entry to the associated variable prior to the Submit button assessing correct/incorrect.
- StephanieSam195Community Member
Im also experiencing the same issue using SL 360. Never had this problem before.
Unfortuantely JS doesnt work :(
- ThomasBleije661Community Member
Thanks!
- aaronkapala-97bCommunity Member
Hi All,
This still seems to be an ongoing issues, I am on a trial version of Storyline 360 as we use Storyline 3 and there is an issue with Text Entry boxes not working correctly on mobile devices so this was the only way I could get my product out for testing at the time.
I have been pulling my hair out trying to get them to record correctly without closing down the Keyboard and using the JavaScript line Matthew has mentioned has done the job - so thank you for your post, this has really saved us.Hopefully this could be sorted soon but also hopefully the updates in Storyline 360 can be replicated in SL3 so that the text entry boxes work correctly on mobile devices.
Thanks for checking in, Aaron. We have this issue open, and we've updated our notes with this information:
On a mobile device, clicking submit directly after entering the text or numeric entry is not allowing the focus to change from the entry field. When the focus doesn't change, the trigger to adjust the entry variable doesn't fire, and the question is evaluated incorrectly.
We are still looking at this behavior, and we'll let you know here about any changes that are released!
Related Content
- 10 months ago
- 10 months ago
- 11 months ago