In my search for a Javascript way to programmatically select WebView content, I encountered this Javascript code snippet, which uses a method named setData() in a member named clipboardData in the window object.
But when I tried to find documentation for it in a Javascript reference, clipboardData was nowhere to be found.
Why?
Isn't window.clipboardData not part of Javascript or DOM?
No, it's not part of any standard. Except for IE, most browsers don't allow clipboard access because of security concerns (you don't want arbitrary webpages reading something sensitive information that you put into your clipboard).
I believe only IE lets you access the clipboard. Older versions of other browsers used to, but this has been switched off by default as a security measure. Users can explicitly turn it on via settings/options/preferences, but this is obviously not ideal in most situations.
The workaround is to use a flash object on the page. Since Flash 10 added more security layers, user interaction is also required now with the flash object (e.g. a click rather than say onload event).
I found and implemented the good work from the well written article at the bottom of my answer. He explains the issue in more detail, with links to official statements from Adobe/Mozilla and supplies a usable and a downloadable example, and the source code to the fla. This is handy if you want to reskin/redesign his button.
I have tested successfully on Windows7 using latest (as at 7/7/2011) Chrome/Safari/RockMelt/FF/IE7/IE8/IE9 and MacOSX(SL) Safari/FF.
The only downside is that it uses flash which is mostly fine except for some mobile platforms and a small portion of (ab)normal users. Also I found you need to access over http (a web server), opening and using the demo page via the file system (i.e. double clicking the html file in Explorer) won't work.
Thanks for sharing Rahul, awesome job.
http://www.rahulsingla.com/blog/2010/03/cross-browser-approach-to-copy-content-to-clipboard-with-javascript
Related
I have a long time stick with Conkeror as my default web browser and get used to configuring/adding new features to my browser using js code with all the XUL Api through the .conkerorrc file. I'm migrating to Firefox since it has better support and is actively maintained by Mozilla. However, one of the feature that I've been missing so much is the dot file, which I can easily configure anything that I like, back up all of them through git and eval the code directly (using Mozrepl) while I'm coding to see the result.
Is there any way that I can inject/execute a sciprt on Firefox startup, for example ~/.firefox/index.js?
There is no functionality in stock Firefox to execute JavaScript code supplied by the user at startup. Functionality like this has been something that has been requested of Firefox since 2006-04-02.
It is trivial to write an add-on in any of the different Firefox add-on types (XUL/Overlay, Restartless/Bootstrap, Add-on SDK, or WebExtensions) which would run whatever JavaScript you desire upon Firefox startup. This could be done to either run code that was included in the add-on (simple), or that runs the JavaScript contained in a file that is loaded from a location external to the add-on (more complex). Which add-on type you used to implemented this would impact which interfaces you had available within the code you write. One drawback of writing your own extension which runs code included in the add-on is that in order to use it with a release, or beta version of Firefox is that you would need to have it signed by Mozilla. While this is a quick and easy process, it does add some additional overhead to the development/test cycle.
You have not specified any of the firefox-addon tags in your question. In addition, you have not described the functionality you desire, except as generalities. It also does not appear to be the intent of your question to ask how you would implement such an add-on. Given those and the fact that there are already multiple add-ons that implement the functionality of running arbitrary JavaScript (including XUL) code supplied by the user, I am not going to supply code here which performs this function.
However, if you are interested in using an already existing add-on, here are a few options:
userChromeJS: This extension was derived from the code originally provided as an example of how to implement the functionality requested in bug 332529. Its first feature listed is: "Complete chrome customization is possible by running custom javascript code or overlaying chrome with .xul overlays." This is an Overlay based add-on with which you can use XUL. This sounds like the functionality what you are interested in obtaining.
uc: "A userChromeJS clone with built-in subscript/overlay loader capability."
Greasemonkey: "Customize the way a web page displays or behaves, by using small bits of JavaScript." This is a commonly used add-on which permits writing more complex JavaScript code. The code is executed in a sandbox, not in the scope of an extension. This is done for security reasons.
Custom Style Script (Inject desired CSS or JS): "Add Custom JavaScript Codes or Styles (CSS) to an specific page or all pages."
I have a web system in Java with JSF 2.0, in a print I should not allow the user to change the number of copies. Then I developed a JNLP printing and then deletes file.
Now I'm trying another approach in Chrome browser.. For example, I inspected the input element in which are inserted the number of copies and marked as hidden.
How can I intercept this element through my system and put it as hidden? Would this be a good approach? Initially I thought of plugin but I think the ideal would be to use jquery or javascript in a generic way for me to easily apply to other browsers.
No, that's a bad approach.
This is part of a privileged URL, chrome://print/. Extensions (and most certainly ordinary web code) cannot touch it unless you specifically set a dangerous flag (on every machine that uses the extension, manually).
Consider that this interface is subject to changes in newer Chrome versions as well, so it may break at any time.
Also, the user always has the option of invoking the system printing dialog (e.g. with Ctrl+Shift+P or with the link in the normal interface) that is not subject to your control.
In general, unfortunately Chrome does not expose any API to work with printing preferences, so trying to wrangle with this interface is probably a dead-end.
Go to http://www.facebook.com/facebook?v=wall, then click on the info tab. The content will be loaded, and the address bar now becomes http://www.facebook.com/facebook?v=info but the webpage didn't reload.
At first I think it is Ajax, but my question is, how do you change the address bar without reloading? I know I can change anchor (#wall) using JS but querystring (?v=wall), how?
It's using HTML5's new history.pushState() feature to allow the page to masquerade as being at a different URL to that from which it was originally fetched.
This seems only to be supported by WebKit at the moment, which is why the rest of us are seeing ?v=wall#!/facebook?v=info instead of ?v=info.
The feature allows dynamically-loaded pages to be properly bookmarked, exchanged etc between JS-supporting and non-JS-supporting user agents. Because if you as a JS user linked someone to ?v=wall#!/facebook?v=info and their browser didn't support JS and XMLHttpRequest, the page wouldn't work for them. The #! is also used as a tip to search engines to download the non-AJAX version.
#Snoob - I'd appreciate it if you accepted #bobince's answer instead, he's was on the right track about the specifics first here. Since I can't delete/remove this until it's unaccepted I'll update it to be as correct as possible.
At the moment it's a WebKit (Chrome, Safari, etc.) specific thing you're seeing (or rather, not seeing), as #bobince points out in other browsers you can see the real URL in the bar:
http://www.facebook.com/facebook?v=wall#!/facebook?v=info\
Where Chrome just shows:
http://www.facebook.com/facebook?v=info
It makes a bit of sense, given this is how you make AJAX Content crawlable with the Google search engine, so their browser recognizes where the content comes from as well.
Correction on the specifics: Webkit browsers are showing the shortened URL facebook wants using the HTML 5 history features you can see the code here (take a look at the HistoryManager) in this case specifically they're using .replaceState() to replace the URL you went to with the direct one available.
Note: This answer may not be valid later (the WebKit specific bit), as other browsers support HTML5 features more and more this may become outdated quickly.
For MooTools developers I recommend checking out cpojer's mootools-history plugin which provides support for the native history API when available, with a fallback to hashes.
I don't have Facebook so I can't check. But I'm 95% sure that it has to be a full page request, the location bar is unwritable because this would be a very useful feature to absure for phishing websites (instead of http://fakeonlinebank.com it rewrite to http://yourtrustybank). It's probably just so fast that your browser appears to only load that part?
But I'm curious to see if someone will correct me on this, because that would mean they have the answer you do want to hear ;)
In chrome, when I paste files into text areas, I end up with the path, e.g /home/antimatter15/sha1.js. The paste event includes a .clipboardData object, with stuff like the standard getData/setData methods. There's also a .files but it's length is always 0. Is there any way to get the file that's being pasted, possibly with FileReader like how files can be dragged.
I looked for something similar some time back, and to my knowledge this is not possible with JavaScript and html alone (at least not in any reliable way). Firefox and IE 9 appear to offer some support for local file reading, but for the vast majority of visitors to a public facing site you will need a Flash, Java, or ActiveX control in order to access the clipboard.
We were looking for this functionality for a helpdesk application and settled on an inexpensive ActiveX control called xStandard. As such, I never did any testing with Java to be able to comment on that part of your question. Hopefully someone else can elaborate on that approach.
Can you provide further information on your userbase and if the OS and browsers are controlled?
I have a HTML file upload field from which I'm reading the file name of the file that the user specifies. The actual contents of the file is never uploaded.
At a later stage, is it possible to construct a link using this file name information so that if the user clicks on this link, the original file is launched into a new browser window? If not, what are the reason for disallowing this behaviour?
The purpose of such a feature is to store links to documents that are available on a mapped local drive or a network share.
Most likely, no.
T.J.'s Crowder answer is correct but do note that on virtually all modern browsers that will work only if the webpage you are viewing (with the input type=file) is itself a file:///.
From your question it appears to be some kind of internal company website, which most likely will have its own web server.
You'll notice that in newer web browsers your client-side code will not actually be able to read the complete pathname of a file chosen by a user. That's a security measure. IE8 provides you with some sort of obviously fake directory name, while Firefox and the Webkit browsers just strip off everything other than the file name.
Thus, I don't think you'll be able to do what you want, at all.
edit: info from msdn: http://msdn.microsoft.com/en-us/library/ms535128%28VS.85%29.aspx
New answer
Since Andreas pointed out (quite kindly!) that my old answer (below), while correct, was almost certainly useless, I thought I'd take another swing at it with something I only learned about a few days ago: The new File API from the W3C.
You won't be able to make much use of this now (except on Firefox 3.6 or above), but before too long it'll find its way into modern browsers. It actually gives you access to local files, as long as the user has explicitly selected the file for you (via an input type="file" element). You still can't see their paths, but you can open and read them from the browser (yes, really). So you could open a new window, open the file, and write the contents to the new window. Whether that will really do what you want is another question (you'll have fun writing binary files to a new window, for instance, even though the File API lets you read them just fine), but hey, it's there.
Old answer
(Although you can do the below, Andreas points out that it won't work on just about any browser unless the page the link is in is also served via a file:// URL. So, not much use then.)
You should be able to use a file:// URL for that, e.g., c:\test.txt becomes file:///C:/test.txt. Then the link just uses the URL and the target="_new" attribute telling the browser to open a new window/tab, e.g.:
<a href='file:///C:/test.txt' target='_new'>link to test.txt</a>