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.
Related
I have a React/TypeScript project, and I am trying to detect if a user has any of Mac OS's high contrast accessibility settings enabled: Invert colors, Use grayscale, Differentiate without color, Increase contrast, or an increased Display contrast setting.
I want to detect these using JavaScript/TypeScript.
So far, I can detect only Invert colors.
How do I detect if a user has any of the other Mac OS accessibility settings enabled?
More information:
The prefers contrast media query is not yet available. I tried it anyway, and it doesn't work.
The inverted colors media query tests only for the Invert colors setting.
Apple's dev docs on color and contrast do not have a solution.
Detecting high contrast use in other browser, OS scenarios
Iam afraid it is not possible its at this moment.
The feature in Objective-C to determine if the accessibility mode is active (boolean AXAPIEnabled(void);) has been deprecated as of 10.9 with no indication that there is a replacement. You can see it on the Apple Developer site. By extension, if developers at that level of the system no longer have access, I expect web developers would also be restricted (just as AppleScript writers seem to not have access).
In general, testing for the presence of assistive technology or activation of assistive features is frowned upon by the users who need it most. It creates the very real risk of both well-intentioned developers breaking these features (perhaps by un-verting the page) and also of allowing bad actors to determine somebody's personal health information.
Altought it might come in future as its in stage 5 (proposal)
https://drafts.csswg.org/mediaqueries-5/#prefers-contrast
Other than that Iam afraid you are facing dead end.
On my last project, this was handled via a little bit UX knowledge. We went down same rabbit hole but what ended up working was user's ability to toggle some accessibility settings manually including High Contrast. I dont think you should invest too much time in answering "how to detect" as in some edge cases your effort will be bypassed if users interact via devices they dont have too much control over (shared PC, outdated devices, OS bugs etc.) Heck, some new monitors provide this feature builtin which is even harder to detect.
But, nothing as reliable as good ol' "Hello {user.name}, here are some settings you can toggle manually in the upper-right".
Happy coding!
This is an old question (2019), but I was wondering this same thing myself in 2022. At least the current macOS Monterey has an accessibility feature "Increase contrast" which state can be detected with:
const prefersContrast = matchMedia("(prefers-contrast: more)");
The other states are "no-preference", "less" and "custom". See here: https://developer.mozilla.org/en-US/docs/Web/CSS/#media/prefers-contrast
For Electron you can use the nativeTheme API and access the nativeTheme.shouldUseHighContrastColors property.
A Boolean for if the OS / Chromium currently has high-contrast mode enabled or is being instructed to show a high-constrast UI.
// in main process
const {nativeTheme} = require('electron');
console.log(nativeTheme.shouldUseHighContrastColors);
Note to OP: I understand this does not solve your issue as you are trying to do this in a browser not an electron app, however I figure that this question may come up in search results for people who are looking to add this functionality in an electron app so I figured I would add an answer.
I want to make the Right-Click don't work in my website or give a error that says: Protected Content! The reason I want to do this is because I don't want others to see my Source Code. I know that you can make the Right-Click to not work but I am not pretty sure about F12. If there is no way to make the F12 key to not work is there any way to hide the Source Code form others? I saw a similar website today. If you right click on this website you get this:
F12 works in this website but the Source Code is hidden anyway. How can I archive similar results? Thanks for your time :)
Answering the question overly honesty:
First you must avoid publishing the site on the Internet. Make it available only on your private machine(s) you have total control of. Make sure there are no USB ports exposed to users etc. Also, no internet access of any kind. They may just download some hacker tools this way. If you do not need text input, even better, keyboard can be used to type in some hacker tools as a source code and this way steal your precious sources.
Next make a custom build of a browser. You may want to use tools like Electron instead of generic browsers this way you will end with app that runs only your website and has no developers tools nor address bar nor anything other that may be used to gain access to your precious source.
Install Linux, create new user account with minimal privileges (no write access anywhere) and let it use X without any window manager. Only your electron app with your precious website and no menus that could be used to access some hacker tools like text editor that may reveal your precious source code. Also, configure the account to have complex random password so that users do not start another session in text mode and see your source code.
Remember that hackers may use means like timing attacks, side channels or other hacky means of stealing your code. To prevent that cover walls of the room you store your computer in with a metal grid to make a Faraday cage. Check all people entering and deny them bringing any electronic devices with them. Same for analog photo cameras or paper notebooks. Better safe than sorry: they may reconstruct your site source code based on how it looks like.
Or just accept the hard truth nobody cares about your website source code. There is plenty of places you may copy paste your code from and your website is not the most interesting one. And if you do that to prevent hackers, you have to write secure code (and test/audit it), not to hide it.
Short answer: Browsers, which render your website, are a client-side technology, and there is no way you can control who is going to see or not see your source code.
Long(er) answer:
Browsers download your website, together with it's source code the website onto users computer. Which means they can manipulate it however they see fit. There are some scripts that can ban right click or other types of interactions, but if you try to stop developers from inspecting code (and if they are ispecting, it's a good bet they are developers) they will find a way even if you block f12 or right click. You can always download website, use crawler, open in notepad, etc. etc.
You may want to investigate minifying and/or uglyfying HTML code, but it's no cryptography - again, if someone wants, they will find a way to undo that.
Also, I'm curious, why would you want to do that?
You can do this using window events but still there are ways to read your code.
For example fetching js without execution or disabling js in browser for a moment.
window.addEventListener('keydown', e => {
if (e.key === 'F12') // detect f12
e.preventDefault()
})
window.addEventListener('contextmenu', e => e.preventDefault())
My friend challenged me to figure out a way to control YouTube (in Chrome) from the computer desktop (Or a program different from Chrome). Basically the idea here is to fire an event where I can handle what to do with certain hotkey combos. Chrome has an api (chrome.commands) that allows for this, but the user must be in chrome for it to fire the event (which makes sense). I would like to discuss any possible alternatives.
I know extensions can have file access to the computer (using chrome.fileSystem api), so I was thinking of having a folder somewhere that had text file(s) that would be written to by a script running on the user's computer. The script could also potentially just be a macro fired by Windows on a certain key stroke.
Is this a practical approach, or are there easier ways to accomplish this? It just seems like there's a lot of "moving" parts needed to make this work.
EDIT: Main goal here is to get skip and pause/play keys (that some keyboards have) to work with chrome. using Ctrl+Shift+[0-9] works with chrome.commands, but anyone have other suggestions to get those other keys to work?
chrome.commands has a very limited set of shortcuts that work globally:
By default, Commands are scoped to the Chrome browser, which means that while the browser does not have focus, the shortcut will be inactive. On desktop Chrome, Commands can instead have global scope, as of version 35, and will then also work while Chrome does not have focus. NOTE: The exception here is Chrome OS, where global commands are not allowed at the moment.
The user is free to designate any shortcut as global using the UI in chrome://extensions \ Keyboard Shortcuts, but the extension developer is limited to specifying only Ctrl+Shift+[0..9] as global shortcuts. This is to minimize the risk of overriding shortcuts in other applications since if, for example, Alt+P were to be allowed as global, the printing shortcut might not work in other applications.
Documentation is available here.
I came across this question referring to alerts and confirm dialogs, like the one created by alert('Hello World!'), while searching for a way to change the text in the 'ok' and 'cancel' buttons (there isn't one). That question, or rather, an answer to that question, indicated that somehow the OS is used to generate the confirm boxes, rather than the browser.
I've hear them referred to as 'native' before, but I had assumed that meant that the dialogs were native to the browser, not the OS.
My question is, what exactly determines the rendering of these dialogs? Is it the operating system, the browser, or some combination of the two? Does the browser handle these on its own, or does it ask the OS to display a dialog, and then catch the result of that?
It's totally up to the implementation within the browser how the alert dialog is created/rendered and different browsers likely do it differently as it is not something that is specified by any standards nor does it need to be. I would expect Firefox to probably use it's own cross-platform XUL tech to render it (just an educated guess). I'd expect IE to use native OS stuff.
The main idea behind those dialogs is that they block execution of javascript (they are blocking prompts) and they are not customizable beyond what the function interface provides.
Is there a way to use Javascript within a browser environment to detect global keystrokes and mouse movements (i.e. all keystrokes and clicks within and outside the browser)? I understand this might involve browser plugins, but would like advice on specific pieces of technology I can look into.
No, this is not possible and that's a damn good thing. We don't need random websites to act as keyloggers.
Any browser plugin allowing a website to do that would actually be malware or at least open a gaping security hole and thus end up on the plugin blacklists of browser vendors really soon.