I have written a debugger for K2 SmartForm web pages, as a Chrome custom panel extension, think of the Vue.js or React Devtools for a similar concept but it is Manifest 2 and I need to convert to Manifest 3.
The debugger injects into the user's SmartForm and sends every event generated on the form to the extension. When a user interacts with the form it might rapidly generate three events or 100 events and as it is user generated, the events may be rather sporadic with long pauses between events.
I use a background script to move messages from page to panel but the background script in its current form is going away. The script needs to be long running but I have read there are some issues with service workers spinning down. I think I can open a new tab to run the background script, not perfect, but it’s an option, as the audience is developers, and they’ll understand the rationale. I also wonder if it is easier than rewriting as a service worker before the end of the year (this is a side project).
What is recommended in the current versions of Chrome for keeping a message channel like this open? If it is the background script in a new tab, is there a sample project I can download?
Related
I'm trying to build a chrome extension that updates its badge every time some event happens on my server- in this case, my server is receiving a webhook from Zoom and then informing my chrome extension that the event occurred. From there my chrome extension will update a counter on its' badge, to show that the event occured. I'm trying to build it according to the chrome extension Manifest V3 but I can't find any info on how to do this correctly.
To my understanding, in Manifest V3 all client-side scripts must run in a service worker. That service worker starts up, runs some code, and then shuts down again. I was planning to open a websocket in my background script, which would have been fine under manifest v2, but I don't think you can do that any more.
My question is: How do I maintain a connection to receive data in my chrome extension? When I say data in this case I really just mean an event informing my chrome extension to update the counter on its badge.
Are there other routes besides keeping a websocket open in the background? I've looked around at things like Google Cloud Messaging but I don't think that was intended for what I would like to use it for.
Try to use an offscreen API, it was introduced some time ago by Google. You just need to check in which browser version this API is available.
This would give you an opportunity on having long living WS connection and communicate with service worker e.g. by runtime API.
EDIT:
offscreen API is available since Chrome 109
In Chrome for Win/Mac/Linux it is possible to have browser addon scripts running before the user launches the browser and after they shut the last browser window. In Chrome this is done by claiming the background permission - see the Chrome extensions API docs on background. Other browsers don't seem to support this permission. So my questions:
Is this also possible with other browsers (e.g. by using some other permission/API...) and with other operating systems (specifically Android/iOS)?
What is the behavior of this feature across different operating systems? (I have tried it with Chrome on Ubuntu and while Chrome does continue running and the script keeps performing its task, it doesn't automatically start in background after restarting the OS - I guess one would have to manually add an autostart script for that)
What I'm trying to accomplish is something similar as to what as been asked here: Display a Chrome desktop notification every day at specific time. But I want to learn about cross-browser-and-OS-compatibility before putting too much effort into it. Also an outlook for what's going to be possible in the near future would be nice. :)
(I am aware that something like this could be done using push notifications, but I would also like my app to work offline, so that's not an option.)
I'm new to Chrome extension development, and I'm a bit struggling with the architecture to put in place.
I would like to develop an extension (browser_action), that, when the button is clicked, opens a window where information will be populated from the WebTraffic.
I figured out I could use the WebRequest API to get info about the traffic.
I could create a popup window, but it's displayed only when I click on the extension button, and hides as soon as I click somewhere else
I tried creating a background window, but it does not show up.
I'd be very grateful if anyone could help me with the initial setup of my application.
Thanks in advance
You need both.
Take a look at the Architecture Overview, or maybe this question.
The lifetime of the popup is indeed equal to how long it stays on screen. It's the UI part, but putting logic there is usually bad.
A background page is permanently there but invisible. It's typically the "brain" of an extension, taking care of heavy lifting and routing messages to other parts.
In short:
You need a background script to collect webRequest information for you in some format.
You need a popup page to show it. Keep in mind it's not guaranteed to be present at a given time and can close at any time.
It's probably best to use Messaging to request the information from the background page. If you need real-time updates, you can use long-lived connections.
In your case you can also tightly couple the two and call chrome.runtime.getBackgroundPage() to directly reference stuff in it.
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.
Sometimes my extension stops working (clicking the browser action doesn't do anything, it stops doing its background activites). I'm debugging that problem.
When it stops working, if I click 'background.html' to open the background page, I get a blank white window instead of the background page (none of the panels open). Reloading the extension from 'chrome://extensions' doesn't allow me to get the background page either. I have to completely quit the browser and restart. If I keep the background page open and then the extension stops working, the JS console doesn't work. I can't use the 'Sources' tab to find out what stack frames are executing etc.
I also noticed that the extension occurs multiple times (multiple adjacent rows) in Google Chrome's own task manager. But I'm unable to select them individually. Clicking one row selects them all.
Anybody seen this before?
Could this occur if my extension code gets into an endless loop? I don't see high CPU usage either at the OS level or in Google Chrome's task manager. Same behavior under both Mac and Linux.
FWIW the extension is relatively complex: it uses web workers, 10s of uploads and downloads in the background page.