koobas.hobune.stream
When opening unity plugin via Chrome, all keyboard input is disabled? (sometimes temporarily, sometimes not)
An App I'm working on, has an issue whereby, opening the page with the Unity plugin via Chrome - has all keyboard input disabled. Sometimes this effect is temporary and keyboard input returns, other times keyboard input is disabled on the page indefinitely.
Does anyone have any similar experiences? Solutions to this problem?
Here are some more techy details....
This line was added:
if(!string.IsNullOrEmpty(Input.compositionString) || !string.IsNullOrEmpty(Input.inputString)) Debug.Log("Input.compositionString: " + Input.compositionString + ", Input.inputString: " + Input.inputString);
which should print out any keyboard input.
When the bug occurred it wasn’t printing out anything. i.e no keyboard input was being reported to the game. This line of code was definitely still be executed as the caret was still flashing.
ps: What "caret" do you mean? do you talk about a GUI textfield? In that case why are you checking Input.XXX? The GUI is soley based on events.
We are seeing all sorts of input problems across a number of unity projects with chrome. Chrome/Unity3d on the $$anonymous$$ac will not accept keyboard input to a simple entry field unless you switch to full screen. It is intermittent but if it does accept input it loses a lot of the keystrokes
We are seeing all sorts of input problems across a number of unity projects with chrome. Chrome/Unity3d on the $$anonymous$$ac will not accept keyboard input to a simple entry field unless you switch to full screen. It is intermittent but if it does accept input it loses a lot of the keystrokes.
We have a similar problem here today using Unity 4.6.3f1 and Chrome OS X Version 41.0.something. When we first load the page, keyboard input works fine. If we switch to another chrome tab and back, all keyboard input is gone until the page is reloaded.
Apparently it's a well-known bug with Chrome OS X and it's been reported several years ago, but the status is unconfirmed :( https://code.google.com/p/chromium/issues/detail?id=166601&q=unity%20input&colspec=ID%20Pri%20$$anonymous$$%20Week%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20$$anonymous$$odified
Are you sure you have actually "clicked" into the webplayer? The webplayer is lika a control. When it's not the active one it doesn't receive key input. That's actually true for most browser plugins. This is even an important security feature. Otherwise if a player has a unity game open in another tab while he's doing some online banking the game could keyspy the login data...
Even when on the same page (which could actually have multiple unity plugins in it) you always have to "make it active" by clicking on it. Take a look at the iTween example page. The "Path-constrained Characters" example uses keyboard input. They made it so when you click on it the webplayer loads and is activated automatically. But if you click for example in the address bar and then on the background of the webpage, the keyboard input won't work anymore. You first have to click again into the plugin area.
edit
The iTween page is actually a bad example :D Unless you left the page at least once they kind of lock the input to the last active plugin. Here's one of my examples. There you can clearly see when you click outside of the plugin you loose the keyboard focus. Once you click inside it's back.
IMPORTANT
The webplayer has another security feature. It will release
the keyboard focus and
mouse locks when the user presses ESC. You should never use ESC as a key in your game. It's the emergancy key to quit fullscreen. This key will ensure the user gat back the control of his browser / PC.
2. edit
Hmm actually i wes wrong. ESC just frees the mouse and disables fullscreen but keep the keyboard focus.
