How can I store preferences for a Google Chrome extension? - javascript

As a simple example, let's say I want to insert a word at the bottom of every webpage, and I want the user to be able to change that word. So I have an options page (within the extension), within which I take user input and use it to call "localStorage.preferences = x;".
Next, the user navigates to http://www.google.com/, and I inject a script which writes the word found in localStorage.preferences. The problem is, since I'm now at a different domain, I'm seeing the localStorage for google.com, not my extension.
How can I share data between my extension's options page and a script injected into some 3rd-party webpage?

It's not, perhaps, the most direct response to your question, but one way to potentially get around this would be to use message passing to fake direct access to local storage from another domain. Assuming you're running your Javascript in the context of a content script, you could pass a message to the background page asking for a key, which would return the contents of localStorage.

Related

Send information from one browser window to another

I have a SPA that I cannot leave due to the fact that if the user leaves/refreshes, some information might be lost.
I want to implement the Instagram API, however the API requires that you browse to a different URL, login, receive a code in your URL, and then get redirected back.
Since I cannot do this directly from my site, I must open a new window to do this.
How can I retrieve the code from the URL in a separate window to send back to my site in the original window?
I have looked at websockets (need a server, so no) and WebRTC (on localhost, did not seem to work) already with no luck. Any suggestions?
If the API allows using an iframe, you can watch what's happening inside the iframe or communicate from inside the iframe using parent.instagramLogin(data) (where instagramLogin is a function you defined outside the iframe).
An alternative option is to automatically close the login tab once the login is finished, and when the main tab is focused again (window.onfocus) send an ajax request to check if the login was completed. (and of course keep checking every time the event fires until you get a result or until it becomes irrelevant.)
Update:
I found a reliable way to communicate between open tabs, using BroadcastChannel if supported, otherwise storage event from localStorage. You can find the details here, and someone in this link even made a small library to make it quick and easy.

Can a javascript code continue running throughout different web pages?

I am trying to code a javascript that runs throughout different web pages. The script should type something into a search bar, click search, click a result, then save each result text into an array. It looks something like:
function returnresults(queries){
arrayofcontent = [];
for each query {
type query in searchbar;
submit search;
result[0].click(); // go to first result
arrayofcontent.push(pagecontent.innertext);
}
return arrayofcontent;
}
The issue is that the script seems to be stopping after the script clicks search, which makes me think that the script is unloading itself when moving to another page, even though I'm typing the script directly into the javascript console in Google Chrome. Does anyone know how to tell Google Chrome to keep running the script even after moving between pages?
Short answer: No.
When you examine what's happening in a browser tab (including working with the console), you are only able to inspect what's loaded in that tab. If you navigate to another page in that tab, everything that was in memory from the last page is thrown out and the new page content is loaded.
What you need is to store the state of the script and then retrieve that state on the other page. Storing state can be done in many different ways (cookies, localStorage, sessionStorage, server-side databases) and you'll need to decide which is right for your architecture and use case.
if you want to inject your script to different web pages you can do that by developing a chrome extension . A extension enables to inject your script depending on your logic
here is the link to get started
https://developer.chrome.com/extensions/getstarted

Multiple 'about:blank' - localStorage

I'm making a bookmarklet, and the bookmarklet goes to about:blank, then stores data under localStorage (technically, it downloads a script that stores data under localStorage)
The idea is that it downloads a script, and stores it under localStorage. That way, it doesn't have to download it again. However, there is no way of ensuring that one of the scripts won't try to edit the contents of another script (in localStorage).
So, I was wondering if it was possible to get a fresh context for localStorage, e.g. via going to about:blank/xyz. However, I do not want this to go to a website, even if the website is specially designed for this. I want this to be entirely local (the entire purpose behind this is to save bandwidth).
Or, being able to somehow sandbox localStorage would work too (in fact, that would be much preferred)
Any thoughts?
TL;DR I want to be able to have a fresh context for localStorage, without accessing a website (e.g. via about:blank, hence the title: Multiple about:blank's)

Javascript file modifying an html file that it is not called from? Jquery Selectors

Is its possible to have a javascript file that is aware of two different HTML files? And how would I do this?
I would like to be able to have two pages. index.html and pictures.html. I have an index.js that changes the display properties of index.html (it puts data based on people into tables and makes it look nice). I would like this current index.js file also to be able to edit the pictures.html file and change information there. index.html would link to pictures.html to display pictures of a person (based on the persons name I have them saved smith1.jpg, smith2.jpg, reagan2.jpg, ect). Is there anyway that this javascript file could get DOM elements based on their id or class of the second file (pictures.html) even though it "lives in" index.html? When i say lives in it is called at the top of the index.html page.
thanks
A script can access elements on another page if it was loaded in some way of connection.
For example, if you make a popup using var popup = window.open(), the return value will contain a reference to the opened popup and this allows access to elements within the popup. E.g. popup.document.getElementById('something'). Pages loaded within frames, iframes and such have similar ways of access.
So yes, if your page loads the second page its script can work there as well. I suggest avoiding this beyond opening and closing popups from a script though; a script should stay inside the box of its page and if it needs to do larger operations on another page, that usually means that you need to change your code architecture a bit.
You'll need to explore server-side programming to accomplish your goal.
http://en.wikipedia.org/wiki/Server-side_scripting
...Or you could write a client-side application in which "pages" are separate views of one actual page or are generated from backing data structures. If you want persistance of what is created/edited, you'll still need server-side programming.
You can use the html5 (group of technologies) postmessage api as well.. This allows you to send messages to another page, and in that page you define an event handler that knows how to handle the message.
This also works across domains.
Here is a blog with an example I just randomly found via google:
http://robertnyman.com/2010/03/18/postmessage-in-html5-to-send-messages-between-windows-and-iframes/
Not possible on the client side if editing the actual HTML file is your goal. If getting pictures to show up depending on stuff a user does on another page is all you care about then there are lots of options.
You can pass small sets of data like stuff the user entered into tables via cookies for accessing the right sets of image files in a pre-established scheme. This would actually persist until a user cleared out cookies.
You could wrap both pages in same-domain iframe elements with the parent element containing just the JS. This would allow you to persist data between pages and react to iframe load events but like everything in client-side JS, it's all gone when you reload the page.
Newer browsers have working file access objects that aren't total security nightmares. These are new and non-standard enough that it would take some doing to make it work for multiple browsers. This could be used to save files containing info that the user would probably have to be prompted to upload when they return to the site.
If the data's not sensitive you could get creative and use another service to stash collections of data. Use a twitter API to tweet data to some publicly visible page of a twitter account (check the Terms of Service if you're doing anything more than an isolated class project here). Then do an Ajax get request on whatever URL it's publicly visible at and parse the HTML for your twitter data.
Other stuff I'd look into: dataURIs, html5 local storage.
Note: None of these are approaches I would seriously consider for a professional site where the data was expected to be persistent or in any way secure regardless of where a user accesses it from.

How can an iFrame from another domain get rid of itself?

I am building a bookmarklet for various sites that functions basically like this:
User navigates to foo.com (an external site not on my control)
User clicks a bookmarklet on his browsers that grabs some information from foo.com and displays it on a form in bar.com inside an iframe
User submits the form inside bar.com which is inside foo.com
The iframe dissapears
The problem is getting the iFrame to remove itself. Since I can't access a function inside a parent domain in another domain I cannot create a custom function parent.removeIFrame() or even do a window.top.location.reload(). I tried many techniques but all of them fail because of cross domain scriptings.
The way I solved it was to change the top.location.href to a custom page I built at bar.com/back.html in which all it does is simply to send a single "history.back()" command that bounces the user on the original page. Althought creative, I don't think it's very elegant solution. Is there a better way?
You can try fragment identifier for cross domain messaging. There is a YUI library for it: http://www.julienlecomte.net/blog/2007/11/31/
When you injected the JS code to create the form on the site's page you can have it poll (js outside of the newly created iframe) your server to know when to remove the iframe. You can use all kinds of methods of doing this including jsonp, long polling, post message, fragment identifiers, etc. You do not need to load a big library for this - the smaller the better for bookmarklets.

Categories

Resources