I'm looking for a way to check if a device supports either the DeviceOrientationEvent or DeviceMotionEvent. To be more precisely I wan't to know if the device really has an accelerometer.
Unfortunately window.DeviceMotionEvent and window.ondevicemotion respectively window.DeviceOrientationEvent and window.ondeviceorientation exists although the device - MacBook Retina - doesn't have an accelerometer.
It's clear to me, that if the Event is never fired, the callback-function of an eventlistener will also never run. But in my case I, my program need's to know if the device has an accelerometer, because the user should receive a notification if there is no accelerometer.
Answers of this post unfortunately didn't work for my problem.
Detecting support for a given JavaScript event?
Given your program needs to have an accelerometer functionality to function, I'm assuming you're blocking its execution if there is none.
So your program could 'block' by default, and listen for a single deviceMotionEvent which will initialize the whole of your program, which will ultimately bind onto window.ondevicemotion. That way you don't need to block the execution for with a setTimeout; a deviceMotionEvent will likely be fired rather quickly after window load.
Related
I know there are lots of javascript plugins and libraries to allow users to pick emojis for text inputs, but windows and mac already have native emoji pickers (⊞ Win. or CTRL⌘Space), Is there a way for me to open these native emoji pickers when a user clicks in a text field instead of installing plugins in my website?
I already tried emulate button key press, but it didn't work at all.
Short answer is no.
In order to access any OS feature from javascript, you need a corresponding browser API to support.
AFAIK, there isn't an API for that. There's a discussion here which suggests adding <input emoji /> to standard but seems no traction gained.
Edit: Below is my original answer, revised. Comments pointed out I was focusing on the wrong aspect of the question, I totally agree.
However, the OP obviously has some wrong idea about what you can do in javascript to leverage browser ability. So I think it's still worth clarification.
You can't send arbitrary emulated keyboard event from js and hoping the OS will respond. Were it possible, it'd be a severe security issue on browser's part. Imagine open a website and it fires a series of keyboard event to your OS and wipes out your desktop (totally feasible through shortcuts).
You need to understand the runtime env inside the browser is basically isolated from the one of native OS. Whatever OS feature that's accessible to your javascript is totally up for browser vendors to decide. For security reason, they are super careful in making these decisions.
Also, make a distinction on "what browser can do", and "what browser allows you to do in js". Seeing Chrome has an "Emoji & Symbols" context menu item, doesn't necessarily mean it decides to grant you the same ability in js.
To further clarify why the emulated keyboard event is fundamentally different from the native one, I include a graph here. The blue arrow is how emulated keyboard event flows. The farthest place it can reach is the browser's internal event bus. It never got a chance to reach the OS event bus, so no way to notify native emoji picker.
I made use of the https://github.com/jaridmargolin/formatter.js library in my project and discovered it is not working properly on mobile devices.
My research showed that this is due to it's use of keypress which is evil and should not be used. So I decided to modify it and use "beforeinput" whenever available. And here lies the problem, how do I detect whether it is available?
I tried this methode: https://stackoverflow.com/a/2877424/13987708
But it doesn't work.
My Internet search only showed me a bunch of different veriations of the same methode when checking for detecting supported events in a browser. And I can see that this method most of the times works. it even works for the "input" event, but unfortunatly not for the "beforeinput" event.
I would love to find a way that does not rely on the user agent, as that is, so I'm told, very unrelyable.
// EDIT
Well, I did research the issue, I even say so in my question :duh:...
The situation is that "keypress" is deprecated and should not be used anymore, in fact in Chrome for Android it doesn't even fire anymore.
The above mentioned plugin to format user input relies on the methode, though.
So I went ahead and replaced it with the "keyup" methode, which indeed fires in Chrome for Android, but only gives a keyCode of 229, so it doesn't work either.
I dug a bit deeper into this whole keyboard events and found that modern browsers support the "beforeinput" event (https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/beforeinput_event).
Which is awesome, it gives you so much mor information about the interaction between the user and your input.
So I adapted the formatter to use the "beforeinput" event instead of "keypress", but my project has to support IE, which does not support "beforeinput".
That's why I need a way to detect if the browser supports this event, and use either the "keypress" or the "beforeinput" depending on the capabilities of the users browser.
And I am aware that a browser might support functionality which the user won't use, but it's not relevant for this use case, I just need to know if the browser will fire the "beforeinput" event or not.
Is there a way to trigger a system-wide keyboard event (i.e. emulate an actual key being physically pressed) from a Javascript Chrome App?
Currently I've got
target.dispatchEvent(new KeyboardEvent(..));
but this can only be invoked on a target element within the browser.
Ultimately, I want to be able to have a callback
function typeLetter(character){ }
that will type a letter character whether Chrome is the active window or not.
Any suggestions greatly welcomed!
I'm pretty sure this won't be possible between different applications. Even between browser tabs would be an issue I think. If it were possible there would be plenty of security issues that come with it.
Emulating key presses anywhere except the currently-running application (chrome) would open up a can of worms in regards to cross-site scripting attacks and key-logging hacks.
Though the title is decently explanatory, I'm curious as how netflix detects how a user is afk. I've looked through the code via chrome's inspect element, and found it may be done through javascript/jquery depending on the mouse position. Is there anyway anyone can verify this or if incorrect, discover the method it is determined? I'm looking to make a plugin to prevent it from pausing.
It's hard to know for sure what Netflix exactly uses to determine if a user has left Netflix, as Netflix probably obfuscates their JavaScript code and it's illegal to reverse engineer it. But there a few possibilities:
A timer that constantly calls document.hasFocus() to see if it has changed.
Most web browsers (Firefox v10+, Chrome v13+, Internet Explorer v10+, Opera v12.10+, and Safari v7+) have a built-in event to check if a window/tab is active or not. Mozilla has documentation on using the visibilitychange event, including an example with a video that pauses or plays when the visibility changes.
Whenever the javascript events onmousemove or onkeydown is called and the page is loaded for the first time, a variable is set to the current unix time. A timer checks this variable to see if so much time has elapsed since the event is called to see if the user has left the window. This is highly unlikely as people may watch a 2 hour movie without ever touching their mouse or keyboard.
There's also this previous question on StackOverflow which includes many different answers to the same question you asked.
I'm currently working on a jQuery plugin that tracks a visitors mouse behavior. Movements, clicks, scrolling and resizing are all recorded and sent, via Ajax, to a location where this data is parsed and stored.
Originally, the data is sent to a script when the user leaves the page. By 'leaves' I'm referring to refreshing, going back and forth though history, closing the window/tab and going to a different address.
The solution works in all browsers EXCEPT for Opera. I'm using jQuery's 'unload' event which isn't supported by Opera at all. Neither is onbeforeunload or onunload.
The question is, how do I implement this kind of functionality for Opera browsers?
One solution I had was to make special use of a 'polling' feature I created. This feature allows you to specify an interval which pushes the content to the server every 'x' seconds. Setting this to 1 second specifically for Opera browsers would probably solve this issue, but it's an awful amount of overhead and the requests aren't always completed in sequence, etc ...
Any suggestions or am I only stuck with the above option?
Thanks!
I suppose I could just link you guys to the plugin source. http://www.thedrunkenepic.com/junk/jquery.mousalytics.js
Regarding the code linked above, adding:
if(window.opera)
{
options.interval = 1;
}
On line 89 works great. My only concern is overhead, so I'm still looking for a more elegant solution.
According to http://bytes.com/topic/javascript/insights/799229-browser-quirk-onload-onunload-do-not-fire-back-forward-refresh-opera, Opera never really fires onload / onunload events, so functionality like this isn't possible without hacks.
http://dev.opera.com/articles/view/efficient-javascript/?page=4 seems to confirm this, and basically states that opera tries to maintain the state of the page across requests.
On further investgation, http://unitehowto.com/Onunload indicates that it might be possible with opera.io.webserver.addEventListener('_close', onunload, false); (where onunload is a previously defined function), however it also indicates that this functionality is not consistent across all versions of opera, and might not work at all.
I think that your best option is probably to use the polling option for Opera, or possibly use a server-side check for the current page and where it falls in the history queue.
Does adding this line of JavaScript work for you?
history.navigationMode = 'compatible';
Source: http://www.opera.com/support/kb/view/827/
I've had the same problem and this saved my day:
if( typeof(opera) != 'undefined' )
{
opera.setOverrideHistoryNavigationMode( 'compatible' );
history.navigationMode = 'compatible';
}
More info about this problem can be found at: http://www.opera.com/support/kb/view/827/