I am a little confused whether this api suits my need. I want a common place to view my logs, instead of going around to the popup's console, the background page's console, etc...
Then I noticed that you can include several background scripts. In which case, which page does the api give us?
Chrome does not support multiple background pages in a chrome extension. It supports multiple background scripts. But it does not supports both background page and background scripts at the same time. See below the screenshots.
Error shown when we try add background page and script at the same
time.
Error shown when we try add multiple background pages.
Now coming back to your question which page getBackgroundPage() retrieve?
Since chrome supports only one background page it will return the only page that you include in you manifest.json.
Related
I'm new to Chrome extensions and would like to understand how all types of scripts/pages work.
Here is my understanding:
First - there are "content scripts", ones that should be used to actually modify the pages.
Second - there is a "background script", designed to work like as a server that you send and receive messages from, but it does not modify the pages' DOM; so it can perform tasks like dealing with storage and communicating between scripts but not modifying the page.
Lastly - there are "popup scripts", they are separated from both content scripts and background scripts, but you can still send/receive messages between them.
The popup scripts can NOT directly modify the page (same as background script), they can only send messages to the other two.
You do not declare them at all in the manifest file, you can just go straight and use them in your popup html file.
In the end only the content scripts can eventually actually modify a page.
Am I correct?
One Chrome extension documentation Link to rule them all, One Link to find them,
One Link to bring them all and in the darkness bind() them1:
>> Architecture Overview <<
(artist's impression)
It should answer many of your questions. However, that would be a bad SO answer, so a summary from me:
Background page/scripts: Only one page exists per extension. It is invisible and can never be displayed in a tab. Normally, it is open as long as Chrome is open, though there are exceptions. Since it's always there and has the highest level of access to Chrome APIs, it's frequently used for main logic / event routing between parts of the extension. In short, background work.
Event page/scripts: A variant of background pages that are unloaded if there is no code running. This saves memory, but introduces complexity as to maintaining state. Chrome remembers which events should be listened to (via addListener) and loads the page again when they happen. Hence, event page.
Besides that, extension can have other, visible pages. You can just open them in a tab (they would have chrome-extension://extensionidgoeshere/page.html address), and they will have same level of access to Chrome API. Two UI types are special to extensions though:
Browser/Page Action popup: A small window that's opened with a click on the corresponding UI element. Unfortunately, it's also very fragile - it will close as soon as it loses focus. Other than that, it's just an extension page.
Options page: Comes in two flavours. Version 1 Options page is just a tab that's opened when invoking options for an extension; Version 2 Options page can optionally show in a special box inside chrome://extensions/. Again, other than that it's just a page with extension privileges.
Finally, having a bunch of pages is fun, but if you want to interact with existing pages/tabs, you'll need to inject scripts in them.
Content Scripts are scripts that run alongside pages; for compatibility reasons, they run in an isolated world. For security reasons, they are severely limited in access to Chrome API. But they share the DOM with the page, and as such can modify it.
Page-level Scripts is something you barely find mentioned in documentation (as "DOM injected scripts"), but they are very useful to break the barrier between extension JavaScript and page's own JavaScript. A good overview of them is presented in this answer by the magnificent Rob W.
Having defined all relevant extension parts, the documentation page also briefly mentions how to communicate between them. For a more in-depth look into this aspect, see this answer (again by Rob W) and the Messaging documentation.
1 Seriously though, every beginning extension developer needs to read that, and this page is not prominent the documentation. Good job, Google.
Is it possible to show chrome extension icon inside the web page?I am able to create an extension using page action ,icon is shown inside the address bar ,but i need to show it inside the web page ...
Well, there is no special API you can simply use for that.
You can inject your own UI elements into the page, but it's going to be difficult. I will only outline this, don't ask for specific code.
You will need a Content Script (also, read the Architecture Overview page if you haven't yet) to access the contents of the page.
Then, you need to create and append your elements to the DOM of the page. In your case, you could possibly add an <img> tag with your icon and a click listener that does something.
Note that to avoid clashes with CSS of the page itself it is recommended to use Shadow DOM techniques.
Of course, this may or may not work well depending on the page you're injecting into.
After many hours of research, I've seen multiple ways to do similar things. But I don't want to pigeonhole myself into approaching this in the wrong way, so I would appreciate any advice on how to achieve the following.
When clicking on my extension icon, I want to load a toolbar onto the current page. This toolbar has a number of links and forms that can:
Interact with the original page (DOM Listeners, changing the DOM)
Create additional extension popups on the original page
Make requests to external resources
From a JS perspective, I think it would be easiest to inject all my own HTML directly on the page and handle functionality via one content script. I abandoned that approach after realizing I'd never be able to account for all CSS conflicts in my popups.
So instead, this is what I have so far. When clicking on my Extension icon, I inject a div into the current page and load up an iframe sourced to a popup.html via chrome.extension.getURL('popup1.html'). This is where I get stuck. By loading my content into an iframe, I have isolated any CSS issues. But say I have text selected on the parent page and I click a button in my popup1.html. Is there then a way to pass the selected text back to the popup1.html or to show that selected text in a new popup2.html?
I hope that once I get the workflow down on how to do this kind of interaction I can move on with development. Thanks for your help!
I wish to run a content script when viewing the source of any web page. (and have a page action icon appear)
The docs here don't mention view-source as a valid scheme.
Is there a way around this limitation?
You cannot insert a content-script into view-source: pages. I didn't found a detailed explanation, but here is the related commit.
I have developed a chrome extension. The extension itself works fine and fast.
But when I start the browser and click on the toolbar icon of my extension it takes about 2 seconds for the popup to appear and to show its content (this happens anytime the browser is restarted).
Any idea what causes this and how to fix that?
Tip 1:
Use your popup page for rendering exclusively. It should be as light as possible. All the heavy loading/processing (localStorage, XMLHttpRequests, blocking javascript) must be done in the background page.
The background page is loaded when Google Chrome starts. Basically, it allows you to execute code and keep a page always running (although the popup is not present). For instance, streaming audio in a html5 tag with no popup.
Note: If you are not using a background page yet, you should be taking a look to message passing first.
Tip 2: Warning: This could fail
I haven't tested this yet, but maybe using the HTML5 manifest.cache can help you preventing loading again resources stored locally. But beware, this is HTML5 and is prone to changes and unstability across versions. (also, I am not completely sure that the cached resources will be loaded in memory before the popup is opened)
Hope it helps!