How can I get all of the visited urls visited in a chrome extension background page - google-chrome-extension

I am trying to create an extension that will (simply) access every url the user views, the larger scope of the project is browser history across multiple computers/browsers for easier browsing history search but that is irrelevant here. My current code will read the url Sometimes, but not every page:
chrome.tabs.onUpdated.addListener(function(tabId, changeInfo, tab) {
if(changeInfo.status == "loading"){
//process url
}
});
How can I get this code to read every single url in multiple tabs? I am doing this in a background page.

You can add a content script that runs on every page and sends a message to the background page with the value of location.href. You can use chrome.extension.sendMessage() for this.

Related

How to automate visiting links then submitting a form?

I'm developing an extension that if opened in a specific page it will collect all forms links in that page, then it should visit each link and fill the form and submit it. i don't mind if it is visible or in the background.
I know how to do these separately:
collect the links
open a link
fill and send a form
but i need help on how can i combine those at once, visit all the links and fill/submit each one. any hint?
I'm looking to do something similar to what i can do with Selenium. but in chrome extension.
Try this:
1: inject the content script to the target page.
The script collect the links, and send the link addresses to background script (service worker) background.js by chrome.runtime.sendMessage().
2: Background script add listener for the message by chrome.runtime.onMessage.addListener(),
and the listener do the following for each link.
const tab = await chrome.tabs.create({url: <url_of_the_ilnk>})
chrome.scripting.executeScript({
target: {tabId: tab.id}, function:yourFunction
});
where, yourFunction() do fill and send form.

Chrome extension WebNavigation listener for hash change

I've been using chrome.webNavigation.onCommitted and onCompleted listeners successfully to detect page changes, but now there are some websites that loads new pages entirely with just URL hash part changed.
And those changes don't fire these two listeners.
Is there any way to instruct chrome.webNavigation API to listen to these changes in URL as well? Or is there any other method in Chrome extension to do it?
chrome.tabs.onUpdated - for all URL changes, needs "permissions": ["tabs"] in manifest
chrome.tabs.onUpdated.addListener(function(tabId, changeInfo, tab) {
if (changeInfo.url) {
console.log('Tab %d got new URL: %s', tabId, changeInfo.url);
}
});
chrome.webNavigation.onHistoryStateUpdated - for changes made via History API
See also: JS methods of detecting page changes available in a content script.

Opening and writing to a new window from a Google Chrome extension sandbox page

(Cross posted here)
Hi,
I have a sandboxed page (specified in my manifest) which is loaded into an iframe in my extension's background page. From within my sandboxed page, I'd like to open a new window and write to it, i.e.:
var win = window.open(); win.document.write('<p&gtHello!</p>');
This works from my extension's background page and from regular web pages, but when invoked from either content scripts or my sandboxed page, the window opens, but I cannot access the win object (it's defined, but empty---console.log outputs "Window {}").
I assume this is due to same-origin policies (with every window being given a uinque-origin within the sandboxed environment). However, since the window opens an about:blank page, I'm confused why this would matter.
Is this a feature? Is there a parameter I can add to my manifest to avoid this? And does anyone know of work-arounds that don't involve using postMessage back to my background page? My ideal solution is to have my sandboxed script open a new window and interact with it directly, not with message passing.
I can provide a full example if necessary, but I'm hoping someone might just know off the top of their head. I'm running Chrome 24.0.1312.57 on Mac and 24.0.1312.68 on Ubuntu if that helps.
Thanks,
Hank
Content scripts, by definition, are part of external regular web pages you load so I'm not really sure how your script could work on a "regular web page" but not the content script. Do you mean the code works when you embed it in your own pages, but not in other pages via the content script?
Regardless, if the script is working properly from your background page, you could always try messaging. (more here: http://developer.chrome.com/extensions/messaging.html)
Script for your sandbox/contentscript:
//send message to background page
chrome.extension.sendMessage({todo: "newWindow"});
In background page:
//create a listener
chrome.extension.onMessage.addListener(
function(request, sender) {
if (request.todo === "newWindow") {
//do your stuff here
var win = window.open(); win.document.write('<p&gtHello!</p>');
}
});
Per the cross-post here, the issue is indeed that the opened window is given a unique origin. This was intentional as the members of the standards working group (SWG) felt that it would be more secure to not make an exception for about:blank pages where they inherit the sandbox's origin.
However, to get around this issue, at least for my purposes, I can use the following method. First, forget sandboxing. This workaround uses an iframe embedded in a background page with the src url set to data:text/html,.... This gives a unique origin to the iframe so it's no longer in extension space. That means eval can be used and chrome apis cannot be accessed. Unlike in a sandbox, windows opened from the iframe share that same origin as the iframe, allowing created windows to be accessed. For example:
In a background html page:
<html>
<head>
...
<script src="background.js"></script>
...
</head>
<body>
...
<iframe id="myframe"></iframe>
...
</body>
</html>
In background.js:
...
document.getElementById('myframe').setAttribute('src', 'data:text/html,'+
encodeURI('<html><head>'+
'<script src='+chrome.extension.getURL('jquery.js')+'></script>'+
'<script src='+chrome.extension.getURL('myscript.js')+'></script>'+
...
'</head><body></body></html>'
));
...
In myscript.js
jQuery(document).ready(function(){
...
// To receive messages from background.js.
window.addEventListener('message', function(e){ ... } );
// To send messages to background.js.
parent.postMessage({...}, '*');
// To open AND ACCESS a window.
var win = window.open();
win.document.write('Hello'); // Fails in sandbox, works here.
// Eval code, if you want. Can't do this from an extension
// page loaded normally unless you allow eval in your manifest.
// Here, it's okay!
eval( 'var x = window.open(); x.document.write("Hi!")' );
// No chrome apis.
chrome.log( chrome.extension ); // -> undefined
chrome.log( chrome.windows ); // -> undefined
// No direct access to background page (e.g., parent).
chrome.log( parent ); // -> Window with no properties.
...
});

Unable to use getBackgroundPage() api from a devtools extension

I am trying to write an extension that adds functionality to the Chrome devtools.
According to the devtools documentation, it says that the pages in devtools support very limited apis. Any API that is not supported can be access by accessing it through the background page, just as what contentscripts does.
Here is the relevant documentation snippet:
The tabId property provides the tab identifier that you can use with the chrome.tabs.* API calls. However, please note that chrome.tabs.* API is not exposed to the Developer Tools extension pages due to security considerations — you will need to pass the tab ID to the background page and invoke the chrome.tabs.* API functions from there.
Here is the source url: http://developer.chrome.com/extensions/devtools.inspectedWindow.html
However, when I try to do that, I get the following error in the console:
uncaught Error: "getBackgroundPage" can only be used in extension processes. See the content scripts documentation for more details.
Here is my code in my devtools.js script:
chrome.extension.getBackgroundPage().getLocation();
What am I doing wrong?
EDIT
I should describe my scenario first, and show how I am implementing it.
What I want to do is to display extra data in a devtools panel related to a webpage. In order to get that data, I will need to send a HTTP request in the same session as the page being debugged, because it requires authentication.
Use Case:
User browses to a particular URL. He is authenticated to the site. He then invokes devtools. The devtools panel opens up and a new panel shows up that has extra data related to the page.
Implementation:
1) DevTools script finds out the url of the page being inspected. If the url matches the site base hostname, then it opens a panel. In the callback of the panel creation, it sends a message to a background page, asking it to download a JSON payload from a debug endpoint on the same site, and then sends it to the devtools extension, wh ich then displays it.
Problems:
1) The background page gets the request, and downloads the URL. However the download is not using the same session as the user, so the download request fails.
2) From devtools window, I got the tabId of the inspected window. I send this tabId to the background page so that it can parse some stuff out of the url. However, chrome.tabs.get(tabId) does not return the tab.
To summarize, I need to
1) Get the background page to download data in the same session as the user's tab that is being debugged.
2) I need to have the background page be able to get access to the user's tab.
The APIs available to extension pages within the Developer Tools window include all devtools modules listed above and chrome.extension API. Other extension APIs are not available to the Developer Tools pages, but you may invoke them by sending a request to the background page of your extension, similarly to how it's done in the content scripts.
I guess the documentation is little ambiguous, By chrome.extension API they mean the Supported API's for content scripts.
So, you can use long lived communication for communication between inspected page and background page
Demonstration:
The following code illustrate scenario where a devtools page need some information from background page, it uses messages for communication.
manifest.json
Ensured permissions are all available in manifest file
{
"name":"Inspected Windows Demo",
"description":"This demonstrates Inspected window API",
"devtools_page":"devtools.html",
"manifest_version":2,
"version":"2",
"permissions":["experimental"],
"background":{
"scripts" : ["background.js"]
}
}
devtools.html
A trivial HTML File
<html>
<head>
<script src="devtools.js"></script>
</head>
<body>
</body>
</html>
devtools.js
Used Long lived Communication API's
var port = chrome.extension.connect({
name: "Sample Communication"
});
port.postMessage("Request Tab Data");
port.onMessage.addListener(function (msg) {
console.log("Tab Data recieved is " + msg);
});
background.js
Responded to communication request and passed trivial information using tab API()'s
chrome.extension.onConnect.addListener(function (port) {
port.onMessage.addListener(function (message) {
chrome.tabs.query({
"status": "complete",
"currentWindow": true,
"active": true
}, function (tabs) {
port.postMessage(tabs[0].id);
});
console.log("Message recived is "+message);
});
});
Sample Output received for trivial devtools.js here
Let me know if you need more information
EDIT 1)
For your question 1)
Can you make you call(s) from browser extension HTML Page\Content Script so same session is shared, i have tried both the ways in a sample and it is working form me, instead of code in background page- make the code in content script or browser action HTML Page.
Let me know if you are still facing problems.
For your question 2)
The following code always fetches current window user is browsing
manifest.json
Ensure you have tabs permission in your manifest.
{
"name":"Inspected Windows Demo",
"description":"This demonstrates Inspected window API",
"manifest_version":2,
"version":"2",
"permissions":["tabs"],
"background":{
"scripts" : ["background.js"]
}
}
background.js
chrome.tabs.query({
"status": "complete", // Window load is completed
"currentWindow": true, // It is in current window
"active": true //Window user is browsing
}, function (tabs) {
for (tab in tabs) { // It returns array so used a loop to iterate over items
console.log(tabs[tab].id); // Catch tab id
}
});
Let me know if you are still unable to get tab id of current window.

Best practice: How to track outbound links?

How do you track outbound links for your web site, since the request is logged on the destination server, not yours?
You can add a quick JQuery script to the page that will track external links and can either redirect them to a file on your server that will track the link and then forward to it, or add an ajax request that will submit on click for external links, and track them that way.
See:
http://www.prodevtips.com/2008/08/19/tracking-clicks-with-jquery-and-google-analytics/
https://web.archive.org/web/20090214024330/http://www.justskins.com/development/how-to-track-clicks-on-outgoing-links/132
Method #1: target="_blank", onclick and Google Analytics Events
Format your outgoing links with the following attributes:
outgoing
Define a javascript tracking function (requires google analytics to be loaded already):
function trackOutgoing(el) {
ga('send', 'event', {eventCategory: 'outbound',
eventAction: 'send',
eventLabel: el.getAttribute('href'),
eventValue: 1});
};
Pros:
Does NOT interfere with normal link behavior
Does NOT require redirecting to another url
Cons:
The onclick is not guaranteed to execute (user or browser could terminate the main window)
Method #2: Redirecting with Javascript and Google Analytics Callbacks
Format your outgoing links with the following attributes:
outgoing
Define a javascript tracking function (requires google analytics to be loaded already):
function trackOutgoingAndRedirect(el) {
var url = el.getAttribute('href');
ga('send', 'event', {eventCategory: 'outbound',
eventAction: 'send',
eventLabel: url,
eventValue: 1,
hitCallback: function() { document.location = url; }});
}
Pros:
Does not require target="_blank"
Higher chance of your event being registered with Google Analytics (compared to Method #1)
Cons:
Overrides the default behavior of links with return false;
Cannot open outgoing links in a new window
Method #3: Using a Redirect URL
Format your outgoing links with the following attributes:
outgoing
On your site you will need to implement a redirect script which is beyond the scope of this answer.
Your redirect script would most likely track the outgoing link and then redirect to the provided url.
Pros:
No Javascript required
Does NOT require Google Analytics
Does NOT interfere with the normal link behavior
Cons:
Harder to trigger Google Analytics Events
Links do not link to their original URL. Which may have negative SEO implications.
Add an onclick or onmousedown handler to the anchor tag. You can see many sites doing this, such as Google.
I don't like the redirect as described by Eric Tuttleman, as you unfortunately lose the 'search engine friendliness' of the link.
I handle this on a site I own by adding an onClick to my outgoing links, which fires a function which sends the link URL and a timestamp to my database. I then wrote a backend which retrieves the data, and lets me view it by such categories as 'Most clicked / 24h', 'Most clicked / 1w' etc.
I hope this helps.
On one system I've worked on, we ended up storing redirects in a database table and creating a redirect page that takes an id as an input. On our content pages, we link to the redirect page with an unique id from this table. Once the redirect page looks up the url via the id from the table, it then sends the client a redirect response, sending them to the ending page.
This does give us logging of external links, and as an added bonus, it makes mass changes to external urls a bit easier in some cases.
Some newer options that work without any hacks as explained in https://css-tricks.com/send-an-http-request-on-page-exit/ are Fetch with the keepalive-flag or navigator.sendBeacon.
keepalive is not yet (Aug. 2022) supported by Firefox (Can I Use), but navigator.sendBeacon works in all modern browsers (Can I Use).
// normal fetch, not guaranteed to work
someLink.addEventListener('click', function(event){
fetch('http://www.testing.local/?origin=classic-fetch');
});
// fetch + keep alive (not working in Firefox as of 103, Aug. 2022)
someLink.addEventListener('click', function(event){
fetch('http://www.testing.local/?origin=fetch-keep-alive', {
keepalive: true
});
});
// navigator.sendBeacon (all modern browsers)
someLink.addEventListener('click', function(event){
navigator.sendBeacon('http://www.testing.local/?origin=beacon');
});

Resources