So I have a Chrome extension which uses Google Analytics for tracking various things. One of those things is the extension version, set using a custom variable every time the background page is started. Now my question is: Which scope should I use, visitor or session level? I can't figure it out based on Google's documentation, and no one else seems to have had this issue. I'm not even sure there's any difference, or maybe it's just something like "it's bad practice to overwrite visitor level variables".
Chrome extensions are have some very specific characteristics and the answer to this question is not applicable to anything that is not a Chrome extension.
From your question I believe you do some basic tracking on your background page, but I assume you also do so on a popup or you fire an event if the user do some action with your extension.
In that case I'll strongly suggest that you use a Visitor Level Custom var.
The problem is that the background page is loaded only once, when the browser opens up, and it's like a tab that stays open and silent, possibly hosting some callback functions for events that may or may not happen.
Because of that once the visitor first loads your extension you'll see a pageview from you background page setting this custom var.
After that there may be a silent period where your extension doesn't track anything, this period can take hours, until hopefully the user interacts with your extensions and tracks additional data to analytics. When it finally happens chances are that over half an hour has passed since the backgroun page loaded. If that is true the visit (or session) that was started by the background page is already over. A visit with no activity for 30 min is closed by analytics. In that case that interaction will spawn a new visit.
If you set the Custom Var as a visit leve variable chances are that when you see interactions on the extension, these interactions won't have the custom var.
This approach has the bad side effect that if the version of your extension changes and the user doesn't reload the browser the version is not going to be updated, and it will be erroneously registered as te old version.
That's very unlikely. And the only way to fix it is to check the version of your app everytime the user does an interaction and set that custom var again. I believe that this is excessive and I don't do it in my extension. Still if you opt for it, it really doesn't matter if it's a visit level or visitor level custom var.
Related
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.
I want to add a button to my visual C++ form that will open with a specific browser. So far for links I've been using:
System::Diagnostics::Process::Start("UrlHere")
Which, as standard, opens with whatever your default browser is.
I'm wondering what the process would be to force the URL to open with a specific browser and if it's possible without the use of ShellExecute?
Edit - You are correct, this is C++/CLI. Removed the C++ Tag.
Edit Edit - Apologies if it came across as misleading. Some slight elaboration;
The buttons will launch to application URL's, some of which can only be used in Internet Explorer, others that CAN (and should) be used in Chrome. This is why I need to avoid using the default browser and have different buttons using different browsers when launching URLs
Before answering the 'how', I'd like to ask the question "should you be implementing this?"
By not launching the user's default browser, you are subverting the user's decision.
Perhaps the user prefers a particular interface, and is willing to live with the incorrect renderings that come with it.
Perhaps the user has a browser addon that they really need, such as a screen reader for the blind.
You are requiring additional software installed that the user may or may not want.
Perhaps the user doesn't want Chrome. Perhaps the user prefers FireFox.
You are saying that you know which browser is best, now and forever.
What if the next version of IE makes it work with the sites that are currently Chrome-only? What if the next version of Chrome fixes the sites that are currently IE-only?
What if the site changes so that it works in more browsers?
Do you go back and release a new version of your software that changes the browser for particular sites?
You're trying to solve a problem that may already be fixed.
Both Chrome and Firefox support a addon that will render a tab using the IE engine. It can be set to automatically activate when certain URLs are seen.
Perhaps there is a browser that already works with all your sites, that you don't know about.
Therefore, my recommendation is no, do not do this. The user has decided which browser they want to use, respect that decision and use the default browser.
That said, here's how you would do it: You could use the CreateProcess method, but you're in managed-land, so you might as well use it. Use the Process class to launch the new process for you.
Process^ browserProcess = gcnew Process();
browserProcess->StartInfo->UseShellExecute = false;
browserProcess->StartInfo->FileName = "C:\\Program Files (x86)\\Internet Explorer\\iexplore.exe";
browserProcess->StartInfo->Arguments = "http://www.google.com";
browserProcess->Start();
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.
How do I create an always-present sidebar in a Chrome browser extension? Do I have to inject something into each page the user views? That seems weird because it would disappear every time the user navigates to a new page. Also, I'd be worried about my code and HTML interfering with the page and I can't possibly test every page on the net to be sure it works everywhere.
It looks like there was an API for this that was just removed? Is this feature dead for good or are there any plans to bring it back?
You have to inject HTML into every page. There was an experimental Sidebar API for a while but it was never developed to state that the Chromium team was happy with. They are still keeping the issue open but it is not currently being developed. You should star the issue if you wish to get updates on it's progress.
Update:
The feature is removed and there is no further development on it.
Quoting from their site:
We will not be proceeding with this feature request. We recognize that there is a significant number of you who will be disappointed with this decision, evidenced in part by the many stars on this issue. We debated it extensively, both inside the team and with members of the community. In the end we decided that the WontFix resolution was more in keeping with Chrome's core value of simplicity.