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 want to code some script (language is not a problem), which will open a site in webbrowser or webbrowser control. but the problem I am facing is that some sites have javascript alerts/confirm (ok/cancel) buttons appear during start or if some error occurs. I don't want the user to click these buttons manually, but write some code which clicks these messages. is there any way to do so?
EDIT:
I have requirement from a client to create a new desktop application or plugin for browser which will send OK message for all confirm or alerts. Please note that I don't have access to code for these websites user want to visit. Hope this will make it more clear.
Depends what are your exact requirements you could check something like Selenium, which is a free and powerful UI automation tool.
If you can be bound to exactly one browser, you could maybe take advantage of augmented browsing tools like greasemonkey.
Although I don't know if this satisfies your requirements - I have a feeling that you require this for mobile, since you are mentioning webbrowser control. But I hope it's a good start point for figuring it out further.
I was looking into a script embedded in a webpage that creates an Outlook appointment and opens it. I tested a sample appointment shared by Brian White: http://www.winscripter.com/WSH/MSOffice/90.aspx
and embedded it in a sample web page, but here are two problems:
The script works only in IE and not in any other browser.
IE issues a security message about an ActiveX control and asks if to enable it.
Do you have any idea how to make it work in all browsers and not to scare users with the ActiveX warning?
Thank you in advance!
The script you've linked to works by creating an instance of the Outlook ActiveX control. As such, no, there's no way to make this work in browsers that don't support ActiveX, which is effectively all of them except Internet Explorer.
As for not scaring the users with the ActiveX dialog box, that's not in your hands. The warning message is a security feature, part of the browser itself, and can only be disabled by changing the browser's settings - which isn't something you can do through code, for obvious reasons!
If it's appropriate to your situation, rather than do this through client-side javascript your could instead use Exchange Web Services on the server-side. This comes with its own set of limitations and things to be aware of, namely (a) it's obviously impossible to open Outlook with this method, and (b) on the server-side you'd require access to the Exchange server and would need to know the username/password of an Exchange user with permission to write to the relevant calendar (which is only going to happen if we're talking about a corporate environment).
Although I realize it is an old post, I wanted to offer another approach.
I notice your question refers specifically to OUTLOOK appointments, but what about using "iCalendar"?
{http://en.wikipedia.org/wiki/ICalendar}
This could offer a wider solution. Also, a page could offer two alternative icons.
One for Outlook, another one using iCalendar, and let the user choose which one to use.
Hope this helps. Cheers.
Marcelo F.
I'd like to be able to make the JavaScript I've got in a web page behave differently by doing something or setting something externally. So there'll be logic checking if(something) execute functionality one, else execute functionality two. I can think of three ways of doing this, but I don't like any of them enough to choose it. At least not unless I can see if there's another blindingly obvious way of doing it that's somehow escaping me at the moment.
Add a harmless query string to the URL (e.g. ?choose_functionality_one=true) and my logic can simply look in the page URL. The reason I don't like this is the case where my code is running inside a cross-domain iframe and I can't even access the page's URL (only the iframe's URL). Yes I could pass the query string to the iframe, but only if I have control over the parent page, and I don't.
Create a cookie in the domain of the page, and my logic can simply look for it in document.cookie. This could be done with a bookmarklet easily enough, and wouldn't suffer from the cross-domain problem, because I simply open a window/tab to the domain where my code is running and run the bookmarklet in that context. This is my front-runner choice at the moment.
Add something to the browser's useragent string and look for that in my logic. Pretty easy on Firefox via about:config, but is less easy with the other browsers, and downright difficult on the Mac. Also, on some browsers, once you've set a custom value, you lose the ability to have the UA get auto-updated when you get a browser update. Your UA's version info is stuck in time to where it was when you first custom'ed it.
Can anyone think of another way that via email/IM/phone I can say to someone "do this" and they'll see the page behave differently for troubleshooting purposes. For the general population who haven't done that though, it's running completely normally.
The simplest option seems to be to make a debug page on your site that will let the user turn the "debug" cookie on/off and then queue your regular site code off the existence of the cookie. I'd suggest making the debug cookie expire in a fairly short amount of time so people don't inadvertently leave it on.
This option has the advantages you are interested in (no user agent modification, works on all platforms, works with iframes) and I can see no disadvantages except that it wouldn't work if someone had cookies off, though a lot of the web won't work without cookies these days so that seems like something you could live with.
In addition, it's also the simplest for your users to use. You can just direct them to the right page on your site and all they have to do is click the desired button to turn it on or off. You can make the page very self explanatory which is certainly much easier than any of the other options.
OK, if you only control code and no HTML, then you could do either implement a keyboard shortcut key that would enable the debug mode by setting the cookie. The instructions could be something like this: put the keyboard focus in X and then press Ctrl-D.
Or, you could implement some special type of click (like a Ctrl-click on some object or in some page corner). In this case the instructions could be something like: Hold down the Ctrl-key and click on object X on the page.
Your JS code could implement either of those shortcuts. You could even put up a prompt (all with dynamically created HTML objects) when the special key/click was engaged to confirm turning the debug mode on or off.
More and more applications are moving to the cloud: Google Docs for productivity apps, Meebo for instant messaging, Gmail for e-mails, Salesforce for CRM, etc.
Yet, I've noticed that, unlike their desktop counterparts, very few of those web apps leverage the mouse's "right click". Most of the time, when right clicking in a web app, I get the standard browser right click menu.
I don't believe it has to do with technical implementation since modifying the right click menu is quite trivial in Javascript.
Is there an actual reason that I am missing?
EDIT: The most popular reason seems to be that it's not what user expect. Another mentioned reason was that some users disable Javascript - which is a valid answer -, but in our case, we can discard this possibility since we're talking about applications that require Javascript regardless of the right click option.
Now, let me expand my question a bit:
Do you think it should stay that way (do you really find the default browser right click menu useful) ?
Would you like to see more application-specific right click menus where they could improve the user interface ?
Most users expect the right-click menu to bring up the browser context menu, so doing it to bring up an app-specific menu is not something they would try.
Mac don't have a "right mouse button", likewise with a lot of touch screen phones etc.
Even on a windows application most normal users (not programmers or power users) don’t think to right clicking when they wish to do something, if they have not learned it off by heart to do the given task they wish to do.
(Also right clicking on most web pages brings up a menu that a normal user does not understand, so they don’t try it more then once.)
So you always have to provide another way of doing the operation anyway.
I believe a very valid approach to web applications is to still keep all the browser features enabled, such as back button, opening things in new tabs, bookmarking, changing font-sizes, and so on.
The browser's right-click context menu is something that I do not want to have taken away by an app.
Now, when you start moving the web app out of the browser into its own window (turning it into a dedicated application, such as Fluid does, and I believe Chrome OS will), without URL bar and back button, then we can talk about the context-menu.
It is not how people are used to work in their browser, you shouldn't change default behavior. Users aren't expecting something to happen when they rightclick.
Just for completeness: Opera has no oncontextmenu and no simple possibility to suppress the context menu on right click.
Giving javascript control over right-clicks gives you something like this: http://periodic.lanl.gov/elements/24.html. I really love this website, but its attempts to keep me from copying text or images (whatever it's trying to do) seriously interfere with my web usage patterns. I always open things in other tabs. I always the right click menu to access the "back" command.
It also irritates me to no end when some web site has a flash animation somewhere that steals my control key (so I can no longer Ctrl+Tab to flip to another tab.
My bottom line: web applications can't supersede the local computer's built in commands. If a web application starts taking over control keys, right clicks, etc., it has crossed the line between local and remote applications. That is a very important line to keep crystal clear.
As others have stated, this is due to history and what users are used to. But I guess this will be changing eventually, as web applications gain more and more importance; currently web apps are "web pages" in a "web browser" app, which is quite weird, when you think about it. It's not the web browser that's the interesting thing any more, it's the web app. Why should it run inside something called a "browser"? At least it shouldn't be that prominent to the user, even if it may make sense technically.
Actually we're seeing this with Google Chrome. It's definitely way more minimalistic than anything that came before. It's almost a "plain window to the Web".
Right click is an expert shortcut both in desktop apps and in the browser. Expert love it, while non-experts ignore it or use it only by rote for specific situations without really understanding it (they probably only use it at all because some expert user told them to). That’s okay. There's nothing wrong with providing something for experts only, either for a thick client or a web app. So, of course, web apps would be better if they included application-specific right click menus. They would also be better if they included accelerator keys for their commands, mnemonics for their pulldown menus, double-click for default actions, and drag and drop for selection, copying, and moving, while we’re on the subject of supporting experts.
Let’s be honest: The reason we don’t do these things for experts is because we don’t want to be bothered with the extra work, not out of some concern about confusing users with the unexpected. And that’s a valid point: a typical web app is used less than a desktop app. “Expert” web app users are thus rarer –few use the web app enough to discover and use the expert features. So why devote resources to something to benefit so few users?
Nonetheless, I want to encourage designers to have application-specific right click menus in their web apps. It is necessary if you want your app to be as usable as a desktop equivalent. If you do have application-specific right click menus, follow these rules:
All right-click menu commands should be available through a separate means, such as a sidebar menu. With right-click being an expert shortcut, you need to provide non-experts access to the same functionality in a way they’re used to. This rule is a standard (e.g., MS Windows), despite the fact that browsers (e.g., MS Internet Explorer) blatantly violate it. This rule also addresses the concern of users who disable Javascript.
Do not remove browser right-click commands that are still relevant. The user should still be able do things like save images on a page, copy a block of text, and open a link in a new tab. In fact, you should try to preserve the order of the browser commands as much as sensible. In general, follow the standards for menu item organization and order. This addresses the concern of the right-click menu being unexpected: As long as the same commands are there in pretty much the same order, it’s no cost to the user who is used to right-clicking for the browser commands.
Use right-click menus consistently. Everything that can have application-specific commands should have those commands available by right-click. If users have to start guessing what does and doesn’t have a right-click menu, they’re just going to give up on it. On the other hand, if they discover it for one item, it’ll encourage them to try it elsewhere, and you want to reward that.
Encourage right-clicking by showing it used for application specific commands in your advertisements, demos, and documentation. You may also want to explicitly show drop-down arrows on your pages (maybe just on mouse-over) wherever app-specific right-click is available. Some expert users will discover your application-specific commands anyway because they right-click for browser commands, but in many situations, the browser right-click commands are so unhelpful even experts don’t right click, so you may have to “push” it a bit.
It's not what users expect.
It's also not particularly "discoverable": like old-school Flash web sites where you had to roll your mouse over a graphic to get the site to do something, right-clicking is not necessarily intuitive.
You shouldn't fiddle with the right click because of a a little thing we call Best Practices! Don't take away my rights as a user to control my experience! I want my right click to do what right clicks do!
The best practice is to make this sort of thing optional to the user. If you want to modify this behavior, make it something users can control in their profile or in the application settings.
For example:
(click to enable)
[ ] Use super special awesome right-click menu
Also, because some people may not have a two-button mouse (I'm looking at you, Apple users).
It is due to a inconsistency between the concept of browsing (which is browser centric) and the use of a web-application (which is application centric, the browser being only the renderer). The right click button would make sense in the second case, but as the web is made for browsing resources, this introduces an ambiguity it will probably never be solved.
Kind of interesting, the fact that the most touted deficiency in macs is the single button mouse, and then the most used interface in the world, the web, is single-button centric.
Personally, the only time I would do it is if I wrote an app which ran inside a plug-in which emulated some sort of editor. Silverlight has this ability now, but I would use it sparingly.
As i read in your forst anwser this is true it would be in the context menu it might mess with some things but as i have madde a btoolbar thta floats for my site to do anything you can use keyboard shortcuts so i see a mild and doom future for right click at all i see toolbars everywhree on websites today
I see two reasons. First of all, people might have javascript turned off, today that might not be the biggest issue of all but it's been following developers since the dawn of web-dev. Which brings us to the second reason, it's not what the users expect.
If you were to talk to someone about usability on the web and you had "hidden" features which were only made visible on right-click(browser context menu popup), this would probably be counted as bad design just because most users aren't use to the idea that the web is evolving into something more than just links and left-clicks(navigation clicking).