more plugin text input focus problems

  • I know this has been an ongoing issue since at least 2014...

    https://krpano.com/forum/wbb/inde…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.focus();
    inputelement.value = i;
    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.


  • Hi,

    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.

    Tuur

  • 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.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!