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.
I'm making a Google Chrome extension that has various parts. It has an iframe, a pop-up and an options page. Currently the iframe and pop-up communicate fine and send the collected data off to a database. However I want to capture some data from the options page (an email address) to be used elsewhere in the app. I planned to do this through capturing the email address and storing it but the code doesn't seem to be working.
I've attached the code I'm trying to use in options.js
function save_email(){
var email = document.getElementById('email').value;
chrome.storage.sync.set({
userEmail: email} );
};
I would hope to see it in local/session storage but nothing is there.
I had created an extension that opens a page from 3 different methods:
right click on an image and clicking on the menu item.
link I create dynamically on each image.
Upload an image in the background pop up.
Once the user clicks on the link or uploads his own image, a new tab is opened with the info of the image he clicked (or uploaded).
I had added the utm_source and utm_campaign to the link but for some reason, the traffic counts as direct traffic and doesn't add the info to the analytics code.
Example url: chrome-extension://leoaaeofnhfjkmghbdngecpnadnolnnj/index.html?utm_source=extension&utm_medium=upload#data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAAAQABAAD/
Other then that issue, tracking is working correctly (sending pageview and events).
Anyone experienced this issue and have a workaround?
After a long investigation I had found a solution:
First, we get the URL params:
var url_string = window.location;
var url = new URL(url_string);
var utm_source = url.searchParams.get("utm_source");
var utm_medium = url.searchParams.get("utm_medium");
Then we make sure to count own domain as referrer:
ga('create', 'UA-xxx-x', 'auto',{'alwaysSendReferrer': true});
And finally we set the source and medium manually before calling for the page view event:
ga('set', 'campaignSource', utm_source);
ga('set', 'campaignMedium', utm_medium);
ga('send', 'pageview', '/xxx.html');
I'm guessing that as the protocol is chrome-extension:// the utm params doesn't handle correctly and also as the referral is the same domain (extension id) it doesn't count as a referral.
Hope this will help someone...
Issue Context:
I am using meteor js for a mobile app.
I have hooked it up with google analytics calls and basically I am using two type of calls:
Screen views
Events
Screen views are just fine, but I'm facing an issue with the events.
When I go to Behavior -> Events -> Screens, in the google analytics dashboard, I can see the URL of every page that has triggered an event under the Screen Name column. My problem is that the page URLs for my login page look something like this:
meteor.local/login?username=*******&password=+++++++&rememberMe=on
Where ******* is an actual username and +++++++ is the corresponding password!
Reason:
Since I have to share this analytics account with multiple people, I do not want this information to be available over here.
Clues:
CLUE 1:
I used to do GET http calls, but I have changed them all to POST and it still has not fixed the issue as I expected it not to pass plain parameters through URL anymore.
CLUE 2:
I've noticed that the default google analytics js framework is working with http and not https. I was wondering if it is calling the analytics server with a GET as well. If so, is there anyway to change that?
CLUE 3:
Here is how I am initiating the GA instance:
(function (i, s, o, g, r, a, m) {
i['GoogleAnalyticsObject'] = r;
i[r] = i[r] || function () {
(i[r].q = i[r].q || []).push(arguments)
}, i[r].l = 1 * new Date();
a = s.createElement(o),
m = s.getElementsByTagName(o)[0];
a.async = 1;
a.src = g;
m.parentNode.insertBefore(a, m)
})(window, document, 'script', '//www.google-analytics.com/analytics.js', 'ga');
ga('create', googleKey, 'auto');
CLUE 4:
I have also noticed that these URLs are getting captured very occasionally. E.g. in the pas 12,500 unique events (about 30,000 total events) it has captured just 9 URLs with the username and password. The remaining 12,491 events have
meteor.local/login
OR
meteor.local/--
OR
localhost/--
as the Screen Name.
CLUE 5:
I have also put 4 "search and replace" global filters on the analytics account to search for this string
meteor.local/.*
and replace it with this one
meteor.local/concealedURI
This does not seem to be working either.
I have added this filter on 4 different fields (Since I still really don't know where the URLs are coming from):
Host Name
Page Title
Referral
Request URI
CLUE 6:
This is how I am calling the GA instance to send the event:
ga('send', 'event', 'button', 'click', eventName);
Okay. So, I had to run a lot of experiments and try out different things to solve this issue.
After trying all the things that I have described in the question, I finally found a way to address this problem.
The main cause of this problem was that I was using a google analytics account set to track an App, to capture the data from an app that was built with meteor js (which basically utilizes cordova).
Using meteor means that my app's screens are actually web pages rendered as a mobile app. It seems like meteor uses URLs to navigate through these screens.
On the other hand, google analytics looks at (and captures) the screen name of an app's page, when an event is triggered from that page. In native apps this screen name will be something similar to "About us", "Contact Us", "Home", etc.
Now since a meteor app is not the same, the screen name returned by meteor is actually the URL of the page that has triggered the event.
This does not have anything to do with the http calls (Whether or not they are GET or POST), because it is the local URL used by meteor for navigating that is being passed down to google analytics and not any http calls.
Solutions
1.
If I had the google analytics account set as a web page tracker, I could have access to "Exclude URL Query Parameters" field and I could potentially exclude username and password as was suggested by #Mike and #PhilipPryde in the comments.
However, I needed to use google analytics set as an app tracker. So, this did not work for me.
Failed
2.
I did put a filter on the whole view in the google analytics and searched for meteor.local/.* and replaced that with hiddenURL. The filters on
Host Name
Page Title
Referral
Request URI
did not work.
But when I put the same filter on
Screen Label
field, it worked.
However, this only looked at the screen names returned by screen view hits and not the event. Thus, this did not actually solve my issue either.
Failed
Finally, I had to do this:
There is a method call on GA instance that lets you set different options up. I ended up using this:
ga('set', 'screenName', 'hiddenURL');
This changed the screen name to "hiddenURL". So, I used this before every event and it worked for me.
My code for sending events to google analytics looked like this:
ga('set', 'screenName', 'hiddenURL');
ga('send', 'event', 'button', 'click', eventName);
PS:
This changes the screen name that was showing up in real-time reports of google analytics to "hiddenURL", whenever someone triggered an event. But, it changes back to a screen name as soon as they go to another page. So, it would not also mess with any of your screen view data either, since it is not being captured as a screen view.
Of course that is because, I pass the screen name to my GA instance every time I send a screen view. So it looks like this:
sendScreenViewToGA = function (screenName) {
ga('send', 'screenview', {
'appName': 'Something',
'screenName': screenName,
'appVersion': x.x
});
}
If I had used the screen name, that is being set on the environment tight now, I would have ended up with all my screen names in analytics set to "hiddenURL".
I really hope this post will help others with same issues and save them some time.
We are trying to set a Radio button to be selected initially when an envelope is created based on certain conditions outside of Docusign.
Testing using the following URL and request body.
https://demo.docusign.net/restapi/v2/accounts/163051/envelopes/49c4ebeb-331d-4cf9-bce7-843be646fbd5/recipients/1/tabs
Body:
{
"accountId":"163051",
"envelopeId":"49c4ebeb-331d-4cf9-bce7-843be646fbd5",
"radioGroupTabs":[
{"documentId":"1","groupName":"RadioGroup","radios":[
{"pageNumber":"2","selected":"True","tabId":"04ad92ed-377b-4389-8ec0-93999385c3f6"}
],
"recipientId":"1"}
],
"recipientId":"1"}
Even though we only have 1 radio tab, we receive this response:
{"errorCode": "INVALID_TAB_OPERATION",
"message": "The Tab specified is not valid for the requested operation. Attempt to create 'text' tab from invalid tab type."}
Why are we getting this response? We have checked and the RadioGroup, tabId, envelopeId, accountId are all valid.
Thanks for your post, looks like you've identified an api bug with the platform. In testing I've found that I can modify other tabs just fine (such as dateSigned for instance) but there seems to be a problem modifying existing radio button tabs.
I've logged a bug with DocuSign, not sure when it will be fixed though. The August release just came out so hopefully by the September release. Will post here once resolved.