I'm developing a chrome extension. When the user goes to the options page, they might modify a setting which will require them to refresh any tabs they have in which they're using the extension. So if the user changes one of these settings, then goes back to a tab which requires a refresh, I'd like to notify them of this in a non-intrusive way.
Is there a part of the API specifically for doing this sort of thing, or some other recommended way of doing it? I was thinking of maybe a little message that comes down from the top of the page, but can be closed, or a popup coming out of the browser action.
You have many options.. To name a few:
Do not require it. As much as you can, make the (presumably) content script adapt to new settings. It's by far a better UX - in some cases.
Least intrusive would probably be to update a browser action / page action icon if you use one.
Both APIs allow a per-tab change of icon/badge. You could also animate it a little to bring attention.
An in-page notification injected into the DOM. Some sort of toast or <dialog>.
Watch tab changes with chrome.tabs events, and do something on activation of affected tab, such as a chrome.notifications notification.
Related
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.
I should note, I'm not a chrome extension expert. However, I'm looking for some advice or high-level solution to a security concern I have with my chrome extension. I've searched quite a bit but can't seem to find a concrete answer.
The situation
I have a chrome extension that needs to have the user login to our backend server.
However, it was decided for design reasons that the default chrome popup balloon was undesirable. Thus I've used a modal dialog and jquery to make a styled popup that is injected with content scripts.
Hence, the popup is injected into the DOM o the page you are visiting.
The Problem
Everything works, however now that I need to implement login functionality I've noticed a vulnerability:
If the site we've injected our popup into knows the password fields ID they could run a script to continuously monitor the password and username field and store that data. Call me paranoid, but I see it as a risk. In fact, I wrote a mockup attack site that can correctly pull the user and password when entered into the given fields.
My devised solution
I took a look at some other chrome extensions, like Buffer, and noticed what they do is load their popup from their website and, instead, embed an iFrame which contains the popup in it. The popup would interact with the server inside the iframe.
My understanding is iframes are subject to same-origin scripting policies as other websites, but I may be mistaken.
As such, would do the same thing be secure?
TLDR
To simplify, if I embedded a https login form from our server into a given DOM, via a chrome extension, are there security concerns to password sniffing?
If this is not the best way to deal with chrome extension logins, do you have suggestions on what is? Perhaps there is a way to declare text fields that javascript can simply not interact with? Not too sure!
Thank you so much for your time! I will happily clarify anything required.
The Same origin policy does indeed protect the contents of the iframe from the main page.
However. There's no way for the user to know whether the iframe in the page belongs to your extension or not. A rogue page could copy your design and impersonate your extension, and ultimately steal the credentials.
The only secure way to get the user to input credentials is through a separate window, popup or tab.
Chrome offers an API to open a window with desired properties, which should be sufficiently flexible to meet your design requirements. See this example, which is also about getting a credentials in a popup window: https://stackoverflow.com/a/10341102/938089
I would like to display the latest top 3-5 entries of my extension change log (TXT file) when it's auto-updated and ideally in a balloon-type event like the one when you have successfully installed an extension. It should show/popup near the wrench-icon area. Like a replacement for #history that GM scripts have.
There are already a few SO questions about how to get extension version like here.
There are also one here to detect if it's an install or update based on version.
It is not desktop notifications I want.
My question is how to make the balloon and populate it with the lines.
An alternative is open my options.html page in a new tab and show the change log entries there somehow. Requires tabs permission in the manifest.json file.
chrome.tabs.create({url:chrome.extension.getURL('options.html')});
Any ideas how to do this?
Or is this impossible to do?
There's neither a mechanism to create a "balloon" notification (that's reserved for native Chrome code), nor to pop out the popup without user interaction. Your automatic notification methods are fairly limited: creating a new tab with a changelog is certainly possible, but not particularly user-friendly (since it will simply open at some arbitrary time, completely remote from the user's intent).
If possible, I'd suggest waiting to notify the user until she interacts in some way with the extension. Clicking on a page-action, for instance, could have some sort of infobar-like note at the top of the popup's UI inviting the user to read more about the update.
I need a truly modal dialog to run in Google Chrome in Windows using extension, where the dialog doesn't allow users to click on other tabs etc. The search results so far seem to suggest that showModalDialog() doesn't give a true modal dialog, and the jQuery examples (like SimpleModal) don't seem to be able to stop users from accessing the other tabs or the other parts of the browser.
Alerts seem to be be working, so I was wondering if there is any other solution to this problem? Or do I really need to write a modal dialog from scratch using Javascript?
Using the hidden div methods in the web pages is not an option because I can't modify them.
You can simply use the native javascript function confirm
But I don't like when I can't do what I want without good reasons.
Furthermore, the user will can always switch to another Chrome window.
No sort of in tab HTML modal dialog will prevent a user from switching tabs. Even alert will allow users to switch tabs. You may be able to achieve this through a NPAPI plugin though.