You are not logged in.

Dear visitor, welcome to Forum. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.


Thursday, June 17th 2021, 5:18pm

more plugin text input focus problems

I know this has been an ongoing issue since at least 2014...…52434#post52434

I basically have a plugin that needs user text input and it fails to receive focus in chrome on a touch device. It does works in Safari on an iPad but most of our clients are using Chrome.

For simplicity, I have reverted to the exact plugin example posted by Klaus back in 2014.

In addition, I have added a touchstart event listener:

inputelement.addEventListener('touchstart',text_click, false);

and the text_click function:

function text_click()
inputelement.value = i;

I can confirm the text input is receiving touch inputs as it increments the i variable each time but the input never received focus and opens the ipad keypad. I've found lots of threads on this over the years but no definitive solution that seems to work for me. What am I missing here? Does anyone have a reliable work around for this? This is a temporary overlay over the pano an I don't need KR Pano interactivity while this text input is displayed so disabling anything in KRPano itself which is hikacking focus is an option.

Thanks. I've been stuck on this for several days now and its driving me a bit crazy.



Posts: 3,508

Location: Netherlands

Occupation: Krpano custom coding / Virtual Tours / Photography / Musician / Recording engineer

  • Send private message


Friday, June 18th 2021, 12:57pm


yes it is a quite annoying thing.
i didn't had a good look at it for years, but it seems when you press a bit longer on the input field the focus comes.



Friday, June 18th 2021, 3:16pm

Thanks for sympathizing Tuur. It is really frustrating! The long touch does indeed work but unfortunately it is a really terrible and unacceptable user experience to have to instruct users to do that and 99.9% of users are just going to give up if it doesn't work on a single touch. It is simply a "broken" implementation and pretty pathetic there has not been a proper solution to this over the past 7-years given how prevalent touch and mobile have become over that time.

I think a workable solution for my use case may be to have the plugin append the text input to the body of the DOM rather than the plugin sprite. I had some success getting that to function properly late yesterday in a simplified testing environment so I'm going to try and implement it today in the actual project. Of course something else may pop up that prevents this from working as it should and I already noticed there will be some blurring challenges as well with this approach but it seems like the path of least resistance at this point.