Posts

Showing posts from 2017

Which instrumentation js library for gmail extensions

There are many addons flying around around gmail (gmass, boomerang etc ..). There will be plenty more with the growing usage of this client. The main question for gmail addon designers is about selecting the appropriate instrumentation method. I fell in the trap a few years ago trying to mess around with the gmail page. I arrogantly threw myself in reverse engineering the gmail page (one of the most complex SPA ever written). Don't do this ... unless you love sudokus and absolutely don't care about project deadlines. I am aware of two instrumentation libraries in the field which greatly ease the job at inserting buttons at the desired standard locations and setting event handlers for getting into the gmail event flow: gmail.js ( https://github.com/KartikTalwar/gmail.js ) inboxSDK ( https://www.inboxsdk.com/ ) I'd recommend inboxSDK  since it is a maintained and well documented library.

On-the-fly javascript interception : solving the sandbox problem.

Use case: Should your extension require to interact with the current page in a very intimate fashion (and there are opportunities for this...) ,  you may encounter the roadblock of the javascript sandboxing: javascript code and data are confined in different contexts. Your content script will therefore not be able to access the JS legitimately imported by the page. Solution: In order to gain access and interact with the data and code available in the page, the solution is to insert a proxy javascript snippet in the page. But you can't do this by simply adding a script tag. Instead, you will need to: Design a proxy script based on a window event listener Identify the script you need to deal with (using browser debugging tools such as chrome devtools)  Intercept the targetted script at load time and modify it. Send commands thru event messages to your proxy which HAVE access. Implementation: 1/ Proxy var proxyCode  = `window.addEventListener('message', 

Any chance to get my extension known out there ? a few numbers from the chrome web store...

Many extensions developers wonder about the methods to reach their customers. Posting an extension on the chrome store and relying on spontaneous user acquisition from there is almost as efficient as throwing a bottle in the ocean... Indeed and as of mid 2017, if you post a new extension on the chrome store, it will be part of the 56K+ already existing extensions. Good luck: Category          Total Accessibility 5071 Blogging 940 BY google 64 Dev tools 5369 News & weather 1860 Photos 1323 Productivity 18914 Search tools 3205 Shopping 2633 Social & communications 7061 Sports 833 Fun 9655 Total 56928 EDIT: Since date this article was orignally published, there have been a couple of initiatives to distribute more precise data about the subject. You'll find here and here two very interesting reports by William Wnekowicz owner of the site ext

Best npm and javascript libraries for extensions

Javascript libraries jquery, jquery-ui : well-known DOM manipulation functions and widgets. Don't forget to include minified version in your addon structure ! materialize, bootstrap: adopt a standard look&feel for your addons. underscore:widely used library to manipulate collections and arrays. Streamline your code ! TLD: url analysis library, allows to dissect urls and separate the various components of a url. NPM modules Despite the fact that most js libraries can be webified for internal addon usage, I mainly use npm modules for my build environment:  after testing grunt, I've adopted gulp for the readability and compactness of the build scripts. I have validated and I'm using the following modules on a daily basis: gulp-vinyl-zip: package all addon files into a single zip file for Chrome store advertisement. crx : package all addon files into a crx file for Chrome firefox-xpi: to package all addon files into a single xpi file for AMO store a

Where are we with Microsoft Edge ?

Customers are very interested with the availability of addons on  Edge and the necessary adjustments to bring to the existing chrome/FF extensions for running them in this new environment. At the time we speak i.e. April,2017, I could collect the following facts from various sources : Edge is strictly available on Windows10 (it requires platform APIs which not available in previous versions). This will slow down the adoption of the browser for some times. Existing Chrome (or webExtensions based FF) extensions can be transparently ported thru two scripts provided by Microsoft ( https://docs.microsoft.com/en-us/microsoft-edge/extensions/guides/porting-chrome-extensions ) Note:  not so transparent since the porting involves 2 new JS files called "backgroundScriptsAPIBridge.js" and "contentScriptsAPIBridge.js" ... Windows Store already includes several known extensions (lastPass, ghostery etc...). Publication method is available but does not cover Edge. 

WebExtensions : the converged future of browser addons

Firefox since FF48 is now proposing the Webextension API which allow to reuse chrome code and APIs with little changes making chrome addons code "99% compatible" with Firefox. Note that Edge the last Windows browser also accepts chrome-like APIs. Hints: - there are a couple of modifications that still need to be brought to the chrome addon repo to make them totally usable in the Firefox context: 1/ locales 2/ manifest.json 2.1 gecko id This one is required by the AMO website to allow registration. Firefox contrary to Chome uses a string id to uniquely identify an addon. 2.2 gecko update_url Don't forget to set this property if you don't host your addon on the AMO site ! 2.3 web_available_resources The chrome manifest file admits wildcards for making resource available, this is not the case for Firefox where you have to explicit mention file names. 3/ some APIs like "notifications" claimed as supported by Firefox