I'm thinking about developing Chrome extension for Gmail and I want to know what are the current best practices.
For instance:
attaching a GPG signature by default to every email
adding an extra button that does something (I have it already)
hijacking action of sending email and prompting me to do complete something
...
(just them examples helping me to discover what is possible)
There are quite a few notable extensions that significantly augment gmail functionality:
http://www.boomeranggmail.com/
http://toolbox.mxhero.com/
http://www.wisestamp.com/
...
(I'm not affiliated with any of them, I just named a few)
One option would be to peek into their source which is located here
~/Library/Application Support/Google/Chrome/Default
But maybe there is (wishful thinking) a good tutorial / set of practises on how to fiddle with gmail UI and functionality?
Gmail extension/gadget API - how to add a button to the compose toolbar?
You will have to create and inject the button programmatically. This will involve quite a bit of scouring the Gmail source code (spoiler: it's ugly).
How to build a chrome extension to add panel to gmail windows?
The greatest long-term challenge you will face is that gmail's layout will change unexpectedly and break email discovery or the modified UI. Both issues either require some cleverness to solve, or will require you to stay up at night wondering whether Google will suddenly break your extension.
http://www.jamesyu.org/2011/02/05/introducing-gmailr-an-unofficial-javscript-api-for-gmail/
They're all building out complex APIs with similar functionality, that can all break independently if Gmail decides to significantly change their app structure (which they inevitably will).
Gmail runs its code through the closure compiler, thereby obfuscating everything. On top of that, Gmail is probably one of the most sophisticated javascript apps out there.
Library by the founder of Parse - https://github.com/jamesyu/gmailr - but haven't updated in 1.5 years.
I can show you what I got so far, and just so know I don't particularly like selectors like .oh.J-Z-I.J-J5-Ji.T-I-ax7
Note: http://anurag-maher.blogspot.co.uk/2012/12/developing-google-chrome-extension-for.html (he also does it, he also uses such an obfuscated selectors)
manifest.json
"content_scripts": [
{
"matches": ["https://mail.google.com/*"],
"css": ["mystyles.css"],
"js": ["jquery-2.1.0.js", "myscript.js"]
}
]
myscript.js
var icon = jQuery(".oh.J-Z-I.J-J5-Ji.T-I-ax7")
var clone = icon.clone();
clone.attr("data-tooltip", "my tooltip");
clone.on("click", function() {
jQuery(".aDg").append("<p class='popup'>... sample content ...</p>");
});
icon.before(clone);
(reusing existing UI elements so my functionality looks natively)
https://developers.google.com/gmail/gadgets_overview
There are Sidebar Gadgets and Contextual Gadgets but they don not offer what I want to achieve.
Gmail Labs is a testing ground for experimental features that aren't quite ready for primetime. They may change, break or disappear at any time.
https://groups.google.com/forum/#!forum/gmail-labs-suggest-a-labs-feature
It seems like the ability to develop Gmail Labs is locked to Google employees.
https://developers.google.com/gmail/
Need help? Find us on Stack Overflow under the gmail tag.
So yes, I would really like to know if there are any tutorials / reference materials out there?
(I reviewed many of the 'Similar Questions' and I'm afraid that my options here are limited, but I would be extremely happy if I shrine your enlightenment upon me)
It looks like you haven't stumbled upon the gmail.js project. It provides a rich API allowing to work with Gmail. However, please note that this project isn't maintained by Google. This means that any changes in the Gmail may break your extension and there is no guarantee that anyone will care to update gmail.js to address these changes.
There is a nice API for interacting with the Gmail DOM here:
https://www.inboxsdk.com/docs/
The getting started example helps you add a button to the compose toolbar.
// Compose Button
InboxSDK.load('1.0', 'Your App Id Here').then((sdk) => {
sdk.Compose.registerComposeViewHandler((composeView) => {
composeView.addButton({
title: 'Your Title Here',
iconUrl: 'Your Icon URL Here',
onClick: (event) => {
event.composeView.insertTextIntoBodyAtCursor('This was added to the message body!')
}
})
})
})
Just ran into this blogpost from Square Engineering Team http://corner.squareup.com/2014/09/a-different-kind-of-scaling-problem.html
It is a chrome extension that displays contact information in the sidebar of Gmail when the user mouseover an email contact. (Just like Rapportive does)
The content script of the app is briefly described. It works as follow :
Check if the current page is an open email using document.location.href != currentUrl (you can also use gmail.js gmail.observe.on("open_email",function()) to achieve this).
Get the DOM element containing the email adress. I found out that this selector works for the sender : $(".acZ").find(".gD")
Insert the element in the sidebar with injectProfileWidget()
I am working on a similar extension that displays contact information pulled from Mixpanel here if you are interested.
Related
I'm trying to make my own version of this open source chrome extension. It's called The Great Suspender. Following is the GitHub link.
https://github.com/deanoemcke/thegreatsuspender/tree/master/src
The context menu has options like "Never suspend this URL." I scanned through all the source but couldn't find that written anywhere. So, where on Earth are the labels for these context menus coming from?
Context menu items are created by some Chrome API. Let's look at the API index: https://developer.chrome.com/extensions/api_index
Aha, looks like chrome.contextMenus API. So let's scan the repository for that.
We see code in the form of
title: chrome.i18n.getMessage('js_context_open_link_in_suspended_tab')
So, that's another API to look up, chrome.i18n. If you've never encountered that abbreviation before, it's short for "internationalization", or enabling your program to be translated.
So, actual strings you're looking for are in the locale files as described by API docs, in _locales subfolder:
https://github.com/deanoemcke/thegreatsuspender/blob/master/src/_locales/en/messages.json
"js_context_never_suspend_page": { "message": "Never suspend this URL" },
That's what you are looking for. Those messages are pulled (in appropriate language, if supported, an in English as default) from messages.json in the locale folders.
I've spent a good few hours trying to crack this myself, having analysed a bunch of other people's work (this is the latest one I've tried to hack Block URL with a specific word somewhere in the subdomain ), and have come up none the wiser.
I feel like the js shouldn't really be that complex, I'm just trying to block a webpage and surface an error message in its place.
This is where I've netted out atm:
chrome.declarativeWebRequest.onRequest.addRules({
id: 'some rule id',
conditions: [
new chrome.declarativeWebRequest.RequestMatcher({
url: {
host: 'www.dailymail.com'
}
})
],
actions: [
new chrome.declarativeWebRequest.CancelRequest()
]
});
The answer at Block URL with a specific word somewhere in the subdomain works as expected. When it does not work, follow the following steps to troubleshoot the problem:
Open the background page's console and look for error messages.
Search for the error message on Google, and try to understand the recommended results. Trustworthy sources include Stack Overflow, the extension documentation, Chromium's bug tracker, the chromium-extensions and chromium-apps mailing lists.
Check whether you have added the correct permissions to your manifest file.
If you have just added the new permissions, make sure that you have reloaded the extension (e.g. by clicking on Reload at chrome://extensions/).
With the information you've provided, I can think of three reasons for failure:
Are you using Chromium beta, Chromium dev (or even Canary)? If not, then either install Chrome from one of these channels, or use the webRequest API instead. The declarativeWebRequest API is currently not available on the stable channel, only on the beta and developer channels.
url is an object of the type UrlFilter. There is no property called "host", if you want to match an exact host, use hostEquals, like this:
url: {
hostEquals: 'www.dailymail.com'
}
You have not added the correct permissions. To get your demo to work, you need to declare the declarativeWebRequest and *://www.dailymail.com/* permissions in the manifest file.
This is probably a simple question but I can't seem to find what I am looking for on the web so here it goes. I have a link on my company INTRAnet site that senior management does not want the employees to see the actual web address (via the source option on the View tab of IE).
Please let me know how I can do this in HTML, asp.net or JS.
Thanks!
:)
You can't. Tell senior management to quit being so secretive.
Not sure if this is what you want, but here is a similar Question:
php encrypt and decrypt
Does it help at all? There is another, but it is a php code:
http://php.net/manual/en/function.mcrypt-encrypt.php
Also, what language are you looking to implement the code?
Alernatively, you can use this site: http://www.iwebtool.com/html_encrypter and on the box you type your html e.g.
This is your post link
Then use the "Encrypt" button. It will return you the javascript you are looking for.
E.g.
"<"Script Language='Javascript'>
document.write(unescape('%3C%61%20%68%72%65%66%
3D%22%68%74%74%70%3A%2F%2F%73%74%61%63%6B%6F%76%65%72%66%6C%
6F%77%2E%63%6F%6D%2F%70%6F%73%74%73%2F%31%35%39%33%34%36%39%
36%22%3E%54%68%69%73%20%69%73%20%79%
6F%75%72%20%70%6F%73%74%3C%2F%61%3E'));
</Script>
No jsFiddle because that javascript isn't allowed.
First and foremost, it's impossible to hide the url from the browser. The browser has to request the webpage from the server, and even if the url was obscured somehow, it would have to be plaintext in the HTTP Request, which would open it up to a man-in-the-middle utility like Fiddler.
Second, this feels like security through obscurity. Resources that certain people shouldn't have access to should be locked down explicitly, not just hidden because the user doesn't know the url (yet).
However, purely as a thinking exercise... I suppose... you could write a handler that knows the real url, uses code to retrieve the content of the page, and then writes that to the response. So the users would see the handler url, but not where the handler is pulling it's data from. However, you'd then have to go to great lengths to find all links and resources on the page and convert those references to also go through your handler.
Of course, practically speaking, I think this concept is silly. There's some problem your senior management is trying to solve, and hiding the url from the user is not the answer.
If upper management is this secretive then it's a safe bet that you also already have IT people who have browsers locked down as well, meaning Internet Explorer. It's possible that your IT team might be able to force the address bar to hide for all browsers within your company. I don't think that this can be done on a per request basis. Meaning that the address bar would either be on or off all the time.
According to this post your IT team might be able to update the registry to hide the address bar like so:
Run following RegKey:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Internet Explorer\ToolBars]
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Internet Explorer\ToolBars\Restrictions]
"NoNavBar"=dword:00000001
Here's a google search that might also offer additional information.
Well rather than making it disappear you can make it hard for others to see through and even impossible for those who have no knowledge of base-64. Here is a code :
var a = document.querySelectorAll("*"), b = 0;
for ( b = 0; b < a.length; b ++ ) {
if ( a[b].hasAttribute("data-href") ) {
a[b].href = atob( a[b].getAttribute("data-href") );
};
};
Now you can call something like this :
<a data-href="aHR0cDovL3d3dy5teWNvbXBhbnkuY29t">Go</a>
By using btoa() I converted "http://www.mycompany.com" to "aHR0cDovL3d3dy5teWNvbXBhbnkuY29t" in base-64 and designed "data-href" to understand the encoding. Behind all this it will look and act like :
Go
Below is the HTML
<a id="LnkEmail" onclick="doMailto('d#s.com');" href="javascript:void(0);">
<span id="LblEmail">ABC</span></a>
Javascript
<script type="text/javascript">
function doMailto(EmailAddress) {
document.location.href = window.open('mailto:' + EmailAddress, 'new window');
}
</script>
In FireFox, it opens the image on clicking the span like below.
Query - In IE 8 - Nothing happens on clicking it. Any Idea ?
The popup selection feature is native to Firefox and is NOT an available feature in Internet Explorer, as Internet Explorer handles association directly from Windows, your operating system. So, whichever program is meant to handle mailto: links on your computer is what will open (most typically, Outlook Express). There is no consistent way to avoid this as you cannot control what a user decides to open that protocol with. MY suggestion is to write a POST asp.net contact form. I'm not an ASP.NET developer myself, but I found this tutorial for you: http://www.jimcobooks.com/tutorials/emailform1/default.aspx
To test this theory: try finding a computer without any mail client (no outlook, outlook express, etc.) Internet Explorer will then prompt for a program to open the protocol.
Another test (the way I tested) I set up Google Chrome to handle all mailto:requests and forward them into my Gmail Webmail interface. When I tested your link, and modified your windowname in jsfiddle ( http://jsfiddle.net/sHYW8/2/ ), Windows asked me if IE could open Google Chrome to Handle the Protocol.
Short answer: what you ask is technically impossible unless you force all your users to install a third party addon for IE. This is the result of Internet Explorer being a part of the Windows Operating System, and Mozilla Firefox is a third party browser that is forced to handle protocols in its own way.
UPDATE
I found a jQuery plugin that uses the API for Gmail, Yahoo! and MSN. It's not a popup, but more of a rollover. I think this is going to be your closest bet.
http://kevin-cantwell.github.com/webmailto/
Good thing for you is that implementation seems easy enough. I would look at the bottom example, it looks pretty slick.
try this:
function doMailto(EmailAddress) {
document.location.href = 'mailto:' + EmailAddress;
}
I think your IE is preventing pop up windows created by javascript.
Just to be clear...
Adriano's suggestion of just using a normal html tag would also work.
Like this:
<a id="LnkEmail" href="mailto:d#s.com">
And as Vishal and Kyle Macey tried to explain:
That "Launch Application" window that pops up in Firefox... that is not a window you can create from a web page. That is Firefox's own window that it shows when a mailto: link is clicked. IE does not offer the same type of window. It usually just opens your default mail client (in your case it would probably be Outlook).
and finally...
Javascript is not the same as JQuery.
JQuery is written in Javascript but JQuery is NOT Javascript.
For IE 7 and 8 only you can't use any space in the window name. Try to change your code to:
window.open('mailto:' + EmailAddress, 'Mail');
If you really want such a list there is a way with pure javascript although it might not be the exact same experience as you currently have in firefox. What you could do is create a modal dialog with javascript showing a number of popular webmail clients and an option "default system client" instead of "Microsoft Office Outlook". The "Choose an Application" would be impossible to include as well. Next, if the user selects the native client you would simply trigger a mailto link as you currently do and in case the user selects for example gmail you trigger a window open of a link along the lines of
https://mail.google.com/mail/?view=cm&fs=1&tf=1&source=mailto&to=info#example.com&body=the+body+of+your+message
with your own variables of course from your mailto link. You would have to figure out the relevant links for different webmail services yourself, but as far as I know, most have these kind of links and gmail and yahoo have for sure.
Below is the working code as you mention
window.open('mailto:' + EmailAddress, 'newwindow');
its working but like FF IE not provide you option to choose mail engine.
If you want to run your code you have to set the default program for mail using set default program.
And you can set only Outlook as the default program. In out look you can bind any thing like yahoo or gamil that way you can use your mailto code for IE.
I think You have to doing coding for that because IE not provide any add on like FF.
For That first you have to chekc if default client mai lis there or not by following code
RegistryKey hkey = Registry.ClassesRoot.OpenSubKey(
"mailto\shell\open\command", false);
if this key is null then no default client is there. so you have to show the mail provides list on popup. and selected provider you have to set as default client mail.
http://msdn.microsoft.com/en-us/library/microsoft.win32.registry.classesroot(v=vs.90).aspx
using above link you can find list of mailto registered on machine for list display.
http://www.pcreview.co.uk/forums/re-add-dword-value-registry-t1401434.html
this link show how to set value in registry.
then execute your mailto code.
The mailing list is an utility features provided by Firefox only. You may or may not not find one software's feature on another similar one. If you don't, you should settle for a work around.
Try to remember that in firefox once the user selects a default mail client, you will not get the popup anymore. So there is no use of attempting to create a solution, that is not going to be permanent.
To trim down your requirement, you are trying to select the mail client of the user. But a website cannot changed the system settings of the user, its simply not allowed. Why? Because it opens many vulnerabilities to the user, if this was somehow allowed.
For support reasons I want to be able for a user to take a screenshot of the current browser window as easy as possible and send it over to the server.
Any (crazy) ideas?
That would appear to be a pretty big security hole in JavaScript if you could do this. Imagine a malicious user installing that code on your site with a XSS attack and then screenshotting all of your daily work. Imagine that happening with your online banking...
However, it is possible to do this sort of thing outside of JavaScript. I developed a Swing application that used screen capture code like this which did a great job of sending an email to the helpdesk with an attached screenshot whenever the user encountered a RuntimeException.
I suppose you could experiment with a signed Java applet (shock! horror! noooooo!) that hung around in the corner. If executed with the appropriate security privileges given at installation it might be coerced into executing that kind of screenshot code.
For convenience, here is the code from the site I linked to:
import java.awt.Dimension;
import java.awt.Rectangle;
import java.awt.Robot;
import java.awt.Toolkit;
import java.awt.image.BufferedImage;
import javax.imageio.ImageIO;
import java.io.File;
...
public void captureScreen(String fileName) throws Exception {
Dimension screenSize = Toolkit.getDefaultToolkit().getScreenSize();
Rectangle screenRectangle = new Rectangle(screenSize);
Robot robot = new Robot();
BufferedImage image = robot.createScreenCapture(screenRectangle);
ImageIO.write(image, "png", new File(fileName));
}
...
Please see the answer shared here for a relatively successful implementation of this:
https://stackoverflow.com/a/6678156/291640
Utilizing:
https://github.com/niklasvh/html2canvas
You could try to render the whole page in canvas and save this image back to server. have fun :)
A webpage can't do this (or at least, I would be very surprised if it could, in any browser) but a Firefox extension can. See https://developer.mozilla.org/en/Drawing_Graphics_with_Canvas#Rendering_Web_Content_Into_A_Canvas -- when that page says "Chrome privileges" that means an extension can do it, but a web page can't.
Seems to me that support needs (at least) the answers for two questions:
What does the screen look like? and
Why does it look that way?
A screenshot -- a visual -- is very necessary and answers the first question, but it can't answer the second.
As a first attempt, I'd try to send the entire page up to support. The support tech could display that page in his browser (answers the first question); and could also see the current state of the customer's html (helps to answer the second question).
I'd try to send as much of the page as is available to the client JS by way of AJAX or as the payload of a form. I'd also send info not on the page: anything that affects the state of the page, like cookies or session IDs or whatever.
The cust might have a submit-like button to start the process.
I think that would work. Let's see: it needs some CGI somewhere on the server that catches the incoming user page and makes it available to support, maybe by writing a disk file. Then the support person can load (or have loaded automatically) that same page. All the other info (cookies and so on) can be put into the page that support sees.
PLUS: the client JS that handles the submit-button onclick( ) could also include any useful JS variable values!
Hey, this can work! I'm getting psyched :-)
HTH
-- pete
I've seen people either do this with two approaches:
setup a separate server for screenshotting and run a bunch of firefox instances on there, check out these two gem if you're doing it in ruby: selenium-webdriver and headless
use a hosted solution like http://url2png.com (way easier)
You can also do this with the Fireshot plugin. I use the following code (that I extracted from the API code so I don't need to include the API JS) to make a direct call to the Fireshot object:
var element = document.createElement("FireShotDataElement");
element.setAttribute("Entire", true);
element.setAttribute("Action", 1);
element.setAttribute("Key", "");
element.setAttribute("BASE64Content", "");
element.setAttribute("Data", "C:/Users/jagilber/Downloads/whatev.jpg");
if (typeof(CapturedFrameId) != "undefined")
element.setAttribute("CapturedFrameId", CapturedFrameId);
document.documentElement.appendChild(element);
var evt = document.createEvent("Events");
evt.initEvent("capturePageEvt", true, false);
element.dispatchEvent(evt);
Note: I don't know if this functionality is only available for the paid version or not.
Perhaps http://html2canvas.hertzen.com/ could be used. Then you can capture the display and then process it.
You might try PhantomJs, a headlesss browsing toolkit.
http://phantomjs.org/
The following Javascript example demonstrates basic screenshot functionality:
var page = require('webpage').create();
page.settings.userAgent = 'UltimateBrowser/100';
page.viewportSize = { width: 1200, height: 1200 };
page.clipRect = { top: 0, left: 0, width: 1200, height: 1200 };
page.open('https://google.com/', function () {
page.render('output.png');
phantom.exit();
});
I understand this post is 5 years old, but for the sake of future visits I'll add my own solution here which I think solves the original post's question without any third-party libraries apart from jQuery.
pageClone = $('html').clone();
// Make sure that CSS and images load correctly when opening this clone
pageClone.find('head').append("<base href='" + location.href + "' />");
// OPTIONAL: Remove potentially interfering scripts so the page is totally static
pageClone.find('script').remove();
htmlString = pageClone.html();
You could remove other parts of the DOM you think are unnecessary, such as the support form if it is in a modal window. Or you could choose not to remove scripts if you prefer to maintain some interaction with dynamic controls.
Send that string to the server, either in a hidden field or by AJAX, and then on the server side just attach the whole lot as an HTML file to the support email.
The benefits of this are that you'll get not just a screenshot but the entire scrollable page in its current form, plus you can even inspect and debug the DOM.
Print Screen? Old school and a couple of keypresses, but it works!
This may not work for you, but on IE you can use the snapsie plugin. It doesn't seem to be in development anymore, but the last release is available from the linked site.
i thing you need a activeX controls. without it i can't imagine. you can force user to install them first after the installation on client side activex controls should work and you can capture.
We are temporarily collecting Ajax states, data in form fields and session information. Then we re-render it at the support desk. Since we test and integrate for all browsers, there are hardly any support cases for display reasons.
Have a look at the red button at the bottom on holidaycheck
Alternatively there is html2canvas of Google. But it is only applicable for never browsers and I've never tried it.
In JavaScript? No. I do work for a security company (sort of NetNanny type stuff) and the only effective way we've found to do screen captures of the user is with a hidden application.