I'm currently having an issue with an extension I'm developing using the Firefox Add-on SDK. For some basic context, the extension executes content scripts using the page-mod api in the sdk. On each of the content scripts some additional javascript is injected into the page itself (we'll call them page scripts). In order to do some complex tasks, the javascript injected into the page can communicate with the content script and which will then in turn make requests to the background process of the extension. Due to the complexity of the extension, when it is auto-updated, it is possible to get into a state where multiple page-scripts running the same code are running on the given content-script.
What I'm wondering is if it's possible for extensions built using the Add-on SDK can be forced to update itself only upon restart. This would mean that the extension won't get reloaded even if the auto-update occurs until a user restarts their Firefox Browser.
If this is not possible, any other solutions would be great.
Though I agree with #Noitidart's comment, you can choose to inject your content scripts from main.js only on restart like so:
const { loadReason } = require('sdk/self');
if (loadReason==='startup') {
//Inject the scripts
}
You'll have to make sure that your old version's content scripts can communicate with the new background scripts without breaking, which will be a pain to test. See here for the other load reasons.
Related
I am developing a Chrome extension that absolutely always needs to run with the newest code.
Now, this is a problem that I am not quite sure how to solve while not going for eval() alike functionality.
I designed it to fetch the newest script from server over HTTPS, then execute it using new Function()
It's absolutely most important to have extension run using newest code for every user and updates managed by Google don't solve that problem cause they are usually delayed or require user to update it manually.
CSP only allows for scripts executed from domain specified by me, but I am also using unsafe-eval although I can encode these scripts using hash for more security.
Scripts require access to page DOM and chrome.* API. I can't just specify them as script src in popup, because that's not the point.
Are there better solutions to this problem?
I have created a chrome extension which is quite big. It relies on external frameworks as well as custom code. The extension manipulates the DOM and my fear is that it would really slow chrome down for some users especially if it is loaded on every tab.
Questions
Are chrome extensions loaded per tab?
Is there an upper or suggested limit to how big your extension should be?
Extensions downloaded by the Chrome browser upon install are subsequently run off of the local disk in order to speed up performance. If a new version of the extension is pushed online, it will be automatically downloaded in the background to any users who have the extension installed.
Answer to the second one I don`t think so.
I can only answer the first question:
chrome extension code might be injected to web page using content script, you need to specify which host you want to inject script to.
So it is not a question of will chrome extension be loaded per tab, you need to specify whether you want your extension to load per tab.
You can request the extension to load only in the web sites that you want it to load.
see content script here
I am working on a Chrome extension that will add content to a particular set of pages. From my research, it sounds like what I want is a content script that will execute for the appropriate pages. I can specify the "appropriate pages" using the content_script.matches manifest.json field.
However, the problem I'm running into is that content scripts run in an isolated world, separate from the rest of your extension.
How I had envisioned my extension was a set of UI pages that would be embedded on the appropriate pages by the content script. The background page would contain the code for build the content of the UI pages. The background page, and by extension, the UI pages, would need access to the various Chrome APIs (e.g., local storage), as well as being able to make cross-domain requests to retrieve their data. However, it seems this is not possible, since the content scripts run in an isolated world, and don't have access to the Chrome APIs that I need.
Message passing allows a content script to send and receive data from the background page, but doesn't allow you to take a UI page and embed it on the current webpage.
I initially thought I was making some headway on this when I was able to make a jQuery AJAX request from my content script for an UI page, but that only gets me the HTML file itself. My UI pages depend on code to programmatically build the content--it's not just a static HTML page. And that "build the page" JavaScript code depends on Chrome APIs that are not available to the content script. So, if I just tried to make all my UI pages and JavaScript resources web_accessible_resources, I could inject them into the page but they wouldn't be able to run.
Which brings me to my question: how can a content script pull down, or embed, UI pages that can invoke code in the background page?
Tldr: you need to read about sending messages between content/background. Its in the docs and many samples.
From what I've been able to find, the architecture I was hoping for (as outlined in my question) is not possible in a Chrome Extension. Chrome's security model requires a different approach. Here's what worked for me.
Make your templates, JavaScript files, and anything that's part of your UI, web_accessible_resources.
Use your content script to load these resources and display them to the user at the appropriate times/locations.
(Almost) any calls to chrome.* API need to be done through your background page or event page. In my case, the "background page" is strictly JavaScript, there's no HTML.
Your content script, and UI, can send messages to your background/event page(s).
This model is not unlike the traditional client/server architecture of a web app. The "background page" is like your server, and your content script can send "messages" (think HTTP request) to the "background page" just like it might send a request to your server.
The background page, just like the server, has access to resources that the content script does not, e.g., the background page can use more of the chrome APIs.
This mental analogy helped me to "redesign" my app in a way that (so far) is working within the Chrome Extension security model. I had originally been thinking more along the lines of a traditional desktop app, where the entire app can do things like make cross domain requests or write to the file system. Chrome Extensions and Apps don't work this way, however.
This is a function that I am Calling to redirect to specific page in phonegap Android platform app.
function redirect(){
var strr = "example.html";
window.location="index.html";
setTimeout("someJSfromSomething(strr)",5000);
}
This cannot be done. And if it can, then it should not be done, for the following reason:
When the page is redirected (or refreshed), the old page is gone. The JavaScript code is evaluated in the context of the old page. If you can still run the code after its host page is dead, then you have a "runaway", or "ghost" script. In hacking terms, you have a "persistent" script that can be potentially used to breach the security. A well designed browser should not allow such script to stay alive, or allocate it any resource to execute. In fact, modern browsers all do this. For this very reason, PDF and Flash plugins are exploited to keep the script running.
I hope I have convinced you what you are asking is not possible. However, you can still have a solution by not refreshing the page. If the index page is your own page, wrap the entire page in a div container and use an Ajax load.
I'm looking to write a JS library\toolkit like Kango. Kango allows one to write JS code which executes in all major browsers. Chrome and Firefox have a nice system which allows for long-running processes to run in a background page, while also running scripts on page load (content scripts) while allowing the two to communicate via messaging.
Unfortunately, IE doesn't really have a straightforward system like this. Instead, it looks like the best solution is to use a Browser Helper Object to load the background/content scripts somehow.
I'm not exactly sure how to get started.
Is it possible for the BHO to run an invisible IE instance which runs the background script so that the background script is executed in a separate environment? If so, how would content scripts and said background page communicate?
How would I make my JS libraries available to both types of scripts? How would a response from a background script (an XMLHTTPRequest object) find its way to a content script?
Thanks in advance.