automate javascript clicks within code - javascript

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.

Related

Minimizing apps via nodejs || plain js

I'm currently working on personal automation project and I want to add 'minimize app' feature.
For example: When I click button, I want to minimize the current browser. I already have window.close(); but this will close the app definitly. I found things like window.minimalize(); or window.minimize();, but none of them worked for me. So is there a way to minimize app?
Edited: It does not have to be only client-side JS, it can be used as terminal based nodejs app. Ex: I type minimize Google Chrome, and it will minimize it.
One Google search for how to minimize browser gives the following result:
There is no way to minimize the browser window within javascript. No, there isn't. However, depending on what you're doing and which browsers you're targeting, you could play around with the blur and focus events of the window to achieve similar effect.
Alternatively, if such control is required, you could always port your code to Electron.js or Neutrino.js, which were made to let you create desktop applications using JavaScript.
Maybe if you post some code and give us a train of thought to follow, we could work something out.

Retrieve CTRL + F Keyword

I'm trying to understand how many users click CTRL+F with jquery script but I want to go deeper and understand which keyword they put into the browser box dialog (or which is highligthed in the web page).
I don't find anything right now.
Anyone can help me on which type of code I have to set up to bring this information? Is it possible or not?
Thanks!
You can't do that, or at least with client side JavaScript. That would be invading users privacy and possibly a security loop-hole in the browsers implementation and even if available it would be patched up very quickly.
Listening for keystrokes won't work as suggested in the comments because as soon as the user is typing into the find dialogue, the typing is happening outside of the pages focus.
Conculsion: There is no way to implement such functionality and interact with the browsers native functionality unless exposed by the browsers API.

Navigation Like Bar on Multiple Websites

I'm currently developing an online learning tool in which users can post links to websites and other users can come along and like or dislike them (adding 1 or deducting 1 to its rating)
At present I'm currently using javascript to create a bookmarklet that once clicked pops up a bar in which users can like or dislike the URL. As expected there are many problems with using this technique; most notable the hassle of having to add the specific javascript into a bookmark.
What I need is a better solution to displaying the like/dislike bar. I was thinking browser extension but that would involve having to code multiple extensions for each different browser. I also considered loading the link within an iframe embedded in the page but iframes are depreciated so I didn't really want to use them.
Wnat I'm wondering is if anyone has any better ideas as to how to display the like bar on the given URLs without users having to go through complicated or annoying installation processes.
Any suggestions will be greatly appreciated!
Thanks
As you pointed out, there are three possible solutions:
1. Websites embed your code voluntarily
This happens with very populare social bookmarking tools only.
Your small service (no pun intented) won't get the market share that people will run after you, so you can forget it.
2. A browser extension
The major players do that: Alexa, Google, Yahoo all provide their own browser extension.
The big advantage is that it gives the best user experience.
It has several downsides:
You need to provide one extension for each browser on each operating system
The user needs to install it, sometimes requiring admin rights. Not all users have that
You probably don't have the man power to develop them
3. A bookmarklet
Works cross browsers
Written in a language you already know (Javascript)
Easy to "install"
There just are no other options for you than to use the bookmarklet.
You should use a script that takes your javascript and packs it into a bookmark. Doing that by hand every time you change something is too chumbersome and you lose joy.

Apple script : Can instruments tool be controlled using apple script

I'm exploring some things on apple script to control Instruments tool
Need help on this. I know "Finder" can be controlled, but still not successful on controlling instruments.
Can anyone please help me on this ?
-Thanks
Kiran
The way to tell if an application is AppleScriptable or not is to attempt to open its scripting dictionary with AppleScript Editor. To do so, open AppleScript Editor, and choose "File > Open Dictionary", or hit ⇧⌘O. You can then choose any application by name, or, if the application you want doesn't show up there, click "Browse…" and navigate to wherever the application lives. If the application is greyed out or won't open, it's not AppleScriptable.
In this case, Instruments doesn't show up in the list for me, so I browsed to /Developer/Applications/; there, Instruments is greyed out, so it looks like it's not AppleScriptable. Your best bet is either to use GUI scripting, which is not ideal, or look into running DTrace scripts from the command line. Unfortunately, I know nothing about DTrace, so I can't give you advice there; nor do I know anything about Instruments, so it's possible that this option isn't enough (although I think it is).

Why isn't "right click" more used in web applications?

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).

Categories

Resources