I'm using google chrome.
These images are lagging the browser, so I need away to access it and clean it all.
You are asking how to solve the wrong problem. If your high-frequency ajax calls return images that they don't need, then you are making bad ajax calls. Deleting the files would be treating a symptom when you should be treating the cause.
Find a way to not download them in the first place. The result of an ajax call can be scoped, filtered, or even parsed manually. There's no reason to allow the full result of your ajax call to store these extra resources that you don't want. If you want to know specifically how to do that filtering, you'll need to post the code that generates your ajax calls.
_generated_background_page.html is a file created by an extension installed into Google Chrome. If you are working on a website (not a Chrome Extension), these files are not delivered by that site and can be safely ignored.
Also... a handful of images won't cause any meaningful lag on a modern browser.
Related
I need to keep a JSON file in the extension's web_accessible_resources so that it can be read by a content script through a synchronous XHR (the synchronous part is important, that's why I'm using a XHR).
However this file is supposed to reflect actions the user takes through the extension's interface, so when the user changes something there, the JSON file is rewritten by the background page (this can happen asynchronously). This way, next time the content script reads the file, it will be up to date.
Is there any way for an extension to modify a file that's listed under its web_accessible_resources?
Alternatively, as a last resource, it would be okay to make the extension open the file in a text editor and have the user directly edit it, but I'm afraid that would make Chrome assume the extension is getting compromised and disable it.
It's not possible to modify the contents of a file in the extension.
What you can do in this situation is to employ chrome.storage.onChanged event.
Your background page updates the information in chrome.storage.
This triggers chrome.storage.onChanged in the content script. You react to it by saving a local copy of the data. You don't even need to query the storage: new data is available in the event.
You access the local copy of the data synchronously.
This does not address the issue of having the data when the content script just starts executing, since you have to populate it initially asynchronously. But a synchronous XHR is a very clunky idea.
Some more ideas are covered here. Any of them are pretty convoluted hacks though, and Chrome's official position is "won't happen".
P.S. And just in case someone comes to this question really seeking variable response to an XHR, one can use chrome.webRequest API to redirect to a data: URI containing the data; the catch is that the URI itself must be constructed / available synchronously.
I dont think this is possible, since this is why there is a fileSystem API. I dont know your special use case, but isnt there a possibility of loading the file once the extension starts? In most cases the loading should be done before the user can even interact.
I've first noticed that the results are not in the HTML received from the server therefore I opened Dev Tools and started looking at the other files that my browser downloaded.
I've noticed that there was only one xhr request named gcosuc and no json( nor xml or other data files downloaded) therefore I thought the code was embedded in the JS itself.
I then searched all the .js files downloaded by chrome and still I could not find where the search results came from.
The I thought that the search results might be inside and iframe element and because of this they are not shown in Dev Tools. With this hypothesis in mind I looked at the HTML generated by the JS after the DOM was loaded thinking that the result might be embedded in an iframe and again I was wrong.
Does anyone have any idea how Google gets and renders it's search results?
As well as I've been able to figure out, it is all done using JavaScript and rendered dynamically as you scroll.
Google+ works similarly. Only what you see on the screen is actually on the DOM and it all disappears as you scroll.
If you are trying to screen scrape the results, I would recommend rendering into a browser and looking at the resulting DOM. I use Chromium.
Made a quick try, and it's indeed an AJAX request. The URI is /s and it passes GET parameters, including what you've search.
The response is some kind of awkward JSON that includes text, styles, and some JS. It's like JSON objects, but separated by this chars: /*""*/
Here's an example (word wrapped because lines are really long):
Edit I add the DevTools requests made by Google:
I have a program where the user does some actions (i.e. clicking on several buttons). I want to record their clicks and the buttons that they click to allow the user to then download a text file with a record of their clicks when they click a separate "download" button. I looked at the File-system APIs for HTML 5, but they seemed to not have cross-browser support. I would ideally like to have this entire file generation and download scheme be entirely client-side, but I am open to server-side ideas as well.
TL;DR: Essentially I'm looking for an equivalent to Java's FileWriter, FileReader, ObjectOutputStream, and ObjectInputStream within Vanilla JS or jQuery (would like to stay away from php, but I'll use it as a last option).
Also, why don't all browsers support the filesystem api? (I'm guessing that it would make MSWord and Pages go out of business with all the open source clientside text editors that could come out.)
Unfortunately the HTML5-File-system is no longer a part of the spec, long story short FF refused to implement because they claimed everything you could do in the File-System API was doable in the HTML5 Indexeddb (which was mostly true). Please see this blog post for more on why FF didn't implement. I do not know IE's story. (I may have exagerated why FireFox didn't implement, I'm still bummed because you cannot actually do everything in indexeddb that you can do in the noew "Chrome File-system API")
Typically if two of those three browsers implement a spec, it stays in the spec. Otherwise that spec gets orphaned. However, I'm fairly certain a large reason the file-system api didn't take off is because of the IndexedDB API (caniuse IndexedDB) really took off when both specs were introduced. If you want cross browser support, check this api out.
That all said if you are still set on the file-system api some developers wrote a nice wrapper around the IndexedDB, the File-system api wouldn't actually supply you with a stream anyway. You would have to keep appending events to a given file given a fileWriter object. you'd then have to read the entire file and send to the server via an ajax request and then downloaded from the server once successfully uploaded.
The better route would be to use the IndexedDB apiwhich as stated on developer.mozilla
Open a database.
Create an object store in upgrading database.
Start a transaction and make a request to do some database operation, like adding or retrieving data.
Wait for the operation to complete by listening to the right kind of DOM event.
Do something
with the results (which can be found on the request object).
Here are a couple tutorials on the IndexedDB.
https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Using_IndexedDB
http://www.html5rocks.com/en/tutorials/indexeddb/todo/
As for giving the user that file, as mentioned briefly before you would have to upload the file to the server and download upon the "download" request. Unfortunately you have to trick the user into giving them the data already on their machine. Anyway, hope this all helps.
My question is quite simple, i need to develop a Google Chrome Extension and by the way create dynamically HTML/CSS files. Basically i was thinking to do this with javascript but it's not possible for security reason. So i'm thinking about using directly Chrome API.
Is there a persistance API with chrome ?
Chrome Extensions use localStorage for data persistence. Check out http://diveintohtml5.ep.io/storage.html for a tutorial.
Note that only strings can be saved to localStorage. You'll need a JSON parser/stringifier if you want to load/save objects.
It is possible to do this with javascript. Chrome is very strict when it comes to calling scripts outside its domain(your extension folder I mean).
1. Make sure you are making js calls from your background page and not your content scripts.
2. If you are making js/ajax calls, note that chrome always sends an OPTIONS request. even for GET requests. So your server have to be able to grant permisions.
I hope these 2 points help your js. However, as everyone is saying, LocalStorage does a really good job.
I'm not completely sure of what you are asking but take a look at Local Storage
Hope it helps!
Basically, what I'm trying to do is simply make a small script that accesses finds the most recent post in a forum and pulls some text or an image out of it. I have this working in python, using the htmllib module and some regex. But, the script still isn't very convenient as is, it would be much nicer if I could somehow put it into an HTML document. It appears that simply embedding Python scripts is not possible, so I'm looking to see if theres a similar feature like python's htmllib that can be used to access some other webpage and extract some information from it.
(Essentially, if I could get this script going in the form of an html document, I could just open one html document, rather than navigate to several different pages to get the information I want to check)
I'm pretty sure that javascript doesn't have the functionality I need, but I was wondering about other languages such as jQuery, or even something like AJAX?
As Greg mentions, an Ajax solution will not work "out of the box" when trying to load from remote servers.
If, however, you are trying to load from the same server, it should be fairly straightforward. I'm presenting this answer to show how this could be done using jQuery in just a few lines of code.
<div id="placeholder">Please wait, loading...</div>
<script type="text/javascript" src="/path/to/jquery.js">
</script>
<script type="text/javascript>
$(document).ready(function() {
$('#placeholder').load('/path/to/my/locally-served/page.html');
});
</script>
If you are trying to load a resource from a different server than the one you're on, one way around the security limitations would be to offer a proxy script, which could fetch the remote content on the server, and make it seem like it's coming from your own domain.
Here are the docs on jQuery's load method : http://docs.jquery.com/Ajax/load
There is one other nice feature to note, which is partial-page-loading. For example, lets say your remote page is a full HTML document, but you only want the content of a single div in that page. You can pass a selector to the load method, as in my example above, and this will further simplify your task. For example,
$('#placeholder').load('/path/to/my/locally-served/page.html #someTargetDiv');
Best of luck!-Mike
There are two general approaches:
Modify your Python code so that it runs as a CGI (or WSGI or whatever) module and generate the page of interest by running some server side code.
Use Javascript with jQuery to load the content of interest by running some client side code.
The difference between these two approaches is where the third party server sees the requests coming from. In the first case, it's from your web server. In the second case, it's from the browser of the user accessing your page.
Some browsers may not handle loading content from third party servers very gracefully (that is, they might pop up warning boxes or something).
You can embed Python. The most straightforward way would be to use the cgi module. If the script will be run often and you're using Apache it would be more efficient to use mod_python or mod_wsgi. You could even use a Python framework like Django and code the entire site in Python.
You could also code this in Javascript, but it would be much trickier. There's a lot of security concerns with cross-site requests (ah, the unsafe internet) and so it tends to be a tricky domain when you try to do it through the browser.