Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conflicts with new Chrome Keyboard lock API #75

Open
derwaldgeist opened this issue Aug 11, 2018 · 3 comments
Open

Conflicts with new Chrome Keyboard lock API #75

derwaldgeist opened this issue Aug 11, 2018 · 3 comments
Labels

Comments

@derwaldgeist
Copy link

Since build 68, the Chrome browser supports the W3C Keyboard lock specification:

https://w3c.github.io/keyboard-lock/

This API defines a global Keyboard singleton object with the methods lock() and unlock().

Since cordova-plugin-keyboard is using the global namespace for its own Keyboard object, there's a conflict now. I noticed this because I was (naively) checking for

if (typeof Keyboard === 'function')

in my code to detect the Cordova plugin. But since Chrome 68, this check will always be true (and broke my app, because I was calling Keyboard.hide() which is not part of Chrome's lock API.

I think it would be best if this plugin wouldn't clutter the global namespace at all, if possible.

@Aarbel
Copy link

Aarbel commented Aug 12, 2018

@cjpearson

@cjpearson
Copy link
Owner

Hi Tom, thanks for catching this. I agree we should use a different location. I think window.cordova is used for other plugins, so it might be the best option.

In the interest of not breaking existing code, we could add the window.cordova.Keyboard API and deprecate window.Keyboard before eventually removing it in a later release. In the meantime, users who need the Keyboard Lock API should be able to get it back using delete window.Keyboard.

@derwaldgeist
Copy link
Author

Thanks for your fast response. Sounds like a valid approach.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants