On Wednesday, I began the rollout of New Tab Redirect 3.0 with some bug fixes and a huge new feature: a built in ‘Apps’ page.
Preface for Searchers
By 9pm of release day for New Tab Redirect 3.0, I lost all faith in humanity. I’m a professional software engineer, so I realize users want what they want and if you can’t or don’t give it to them they get really bitchy. But, New Tab Redirect is free software so I technically have nobody to answer to. I’m a human and I make mistakes. I rolled out to 50% of users and forgot to add an explanation of the permissions changes to the description on the web store and to the wiki. Luckily, one user submitted an issue and another emailed me. That’s two users out of 750,000/2 users.
For anyone looking for an explanation of the new permissions, I’ve explained it on the wiki. If you read the explanation and still don’t agree with the added permissions, use another extension… it’s that simple. Don’t be a jerk and call me names or suggest that I’m doing something illegal with no grounds for such defamation. I have no respect for people who intentionally hurt others. One person went as far as to say I had a huge ego; really… I don’t see how giving people something for free and continuously improving and maintaining it for 5 years means I have a huge ego. But, whatever. The rest of this post is about some awesome technical stuff in the new version, namely the New Tab Redirect ‘Apps’ page.
Why a new version?
When Chrome 33 removed chrome-internal://newtab (which pointed to the ‘good’ New Tab Page), I realized that I could create something that I actually wanted personally, while at the same time fixing the whole ‘address bar does not focus’ problem all users targeting chrome://apps were having. Because New Tab Redirect actually redirects to the user’s optional URL, the focus that Chrome gives to New Tab override pages gets lost. That’s just how it is. I’ve documented workarounds on the extension’s wiki.
Another reason for the new version is because Google is cracking down on extensions. Extensions must now have a single visible UI. In other words, although New Tab Redirect 2.2 opened a welcome page and provided an options page, there was no user interface. It was a ‘New Tab Override’ page that didn’t directly offer an override of the new tab page. In other words, there was no default override on installation. I fixed that by creating the override page I wanted by default (I used chrome-internal://newtab). Doing this also meant I would get 5-10 less emails each week from users saying “I use chrome://apps, but I wish the address bar would focus so I could search just like the old new tab page”. Done and done.
Technology: AngularJS
At work, we’ve been using AngularJS on a new project. I’m really loving it. I decided to use AngularJS for the New Tab Redirect ‘Apps’ page because it would mean minimal, reusable code with a clean structure that my users could read and understand.
AngularJS is really web development for engineers. Normal JavaScript is often written with all kinds of haphazardly-structure files, crazy include structures, and continuation passing style causing ridiculously nested functions and hard to read code. AngularJS offers a clean modular structure with a service locator, dependency injection, and the ability to declaratively extend HTML.
The main parts of AngularJS are:
Services
Singletons that provide some shared functionality. A Singleton means there will be one instance of an object in the application a time. An interesting thing about services in AngularJS is that you can actually create factories with static data via services.
Factories
Factories are like services, except they’re meant to represent something that is created anew every time it is injected into a controller.
Controllers
Controllers are blocks of code meant to be tied directly to blocks of the DOM (either directly, via routes, or via directives).
Directives
Directives are constructs in AngularJS that allow you to define new HTML elements or attributes that can be applied at runtime to existing elements.
Scope
Probably the hardest part of AngularJS to grasp is the concept of ‘scope’. It’s not the same as JavaScript scope. In AngularJS, scope can be considered the same as the model in the MVC pattern; it’s bound to the view via the controller. AngularJS does dirty checking on the scope to incorporate two-way binding. That just means changes in the DOM to scope-bound properties will immediately be available in the controller, while changes in the controller that are done within an angular digest get updated in the DOM. Generally, there’s no need for manually binding event listeners.
If you want to learn more about AngularJS, the tutorial on angularjs.org is an excellent place to start.
Technology: Chrome Extension APIs
Chrome JavaScript APIs for extensions are really a pain in the ass. In order to use functionality, extensions must ask for permissions. However, Google doesn’t offer read-only permissions. This caused a lot of contention in the permissions request for New Tab Redirect 3.0. If you’re writing an extension and you plan to add some functionality that requires a permission that says ‘Read and modify’, my suggestion is that you don’t add that feature.
In order to create an ‘Apps’ page that somewhat resembled the old New Tab page, I needed:
- bookmarks (permission: bookmarks, Read and modify your bookmarks)
- Most Visited Sites (permission: topsites, Read and modify your browsing history.. yeah the description is stupid)
- Apps management (permission: management, Manage your apps, extensions, and themes)
- chrome://favicon/ (no permissions needed)
The permissions I needed were only:
- pulling up to 40 bookmarks from the bookmarks bar only
- querying top sites (the API call only gives you 20 sites, why describe it as Read and modify your browsing history?)
- apps management, not extensions and not themes
I can only imaging that Google has a hard enough time as a company, considering how they’ve dropped quite a few products that I loved. They’ve also invested a lot of time in technologies like Google Glass and cars that can drive themselves. They’re likely not at all interested in making a more robust permissions system for extension developers.
The permissions required for the New Tab Redirect ‘Apps’ page are what they are. So many users got scared and even went as far as to falsely accuse me of anonymously collecting their data. The extension is open source, so accuse away: you’re completely wrong. Then again, people that use Google Chrome and think Google is not stealing gobs and gobs of their data are ignorant to the many mechanisms built into Chrome specifically to steal their data. Consider the data stored at chrome://predictors/: if Google has 1 billion Chrome users, they can now collect data from 1 billion distributed machines that tells them what users type into the address bar and where that user ends up navigating. Extension developers are the least of your worries (like you, I don’t trust extension developers either).
The code, a brief walkthrough
New Tab Redirect previously loaded redirect.js, which simply redirected to a page defined on the options page. I wanted to keep this functionality, but at the same time I did not want the New Tab Redirect ‘Apps’ page to start loading if the user defiend an optional redirect.
app.js
AngularJS makes that easy. You can provide a flag to defer bootstrapping of the application until you explicitly tell angular ‘Go!’:
window.name = 'NG_DEFER_BOOTSTRAP!';
This just has to be declared before you call angular.run(). Then, when you’re ready, you call:
angular.resumeBootstrap();
Then, angular will begin wiring itself up to the page. In this way, the new ‘Apps’ page DOES NOT LOAD unless the user is using that page.
One interesting hurdle when writing an AngularJS application for Google Chrome Extensions is that AngularJS wraps some standard HTML elements like a, input, img, and form. I’m only using anchor tags and images in New Tab Redirect, but I didn’t undrestand why images for Apps wouldn’t load. The problem is that for images, you have to whitelist the chrome protocol, and for anchor hrefs you need to whitelist chrome-extension so the AngularJS compiler will be happy with the rendered HTML. This all gives the following clean app.js:
'use strict';
// Setting the window.name property in this way allows us to call app.run(), but block until it's ready to be resumed.
// the resume happens in redirect.js if no redirected new tab url has been specified.
window.name = 'NG_DEFER_BOOTSTRAP!';
var app = angular.module('newTab', ['newTab.controllers', 'newTab.directives', 'newTab.filters']);
app.config(['$compileProvider', function($compileProvider) {
// see https://github.com/angular/angular.js/issues/3889
$compileProvider.imgSrcSanitizationWhitelist(/^\s*(https?|ftp|file|blob|chrome):|data:image\//);
$compileProvider.aHrefSanitizationWhitelist(/^\s*(https?|ftp|mailto|tel|file|chrome|chrome-extension):/);
}]);
app.run();
controllers.js
The new ‘Apps’ page has a single controller on the main page. When it loads, it checks for the user’s synced preferences, then loads apps followed by bookmarks and top sites only if the user wants to load them. The cool thing about AngularJS is how clean doing this becomes (I’ve removed function logic below for brevity full file here):
'use strict';
var controllers = angular.module('newTab.controllers', ['newTab.services']);
controllers.controller('MainController', ['$scope', 'Apps', function ($scope, Apps){
var enable_top_key = 'ntr.enable_top',
enable_bookmarks_key = 'ntr.enable_bookmarks',
bookmarks_count_key = 'ntr.bookmark_count',
top_count_key = 'ntr.top_count';
$scope.extension_name = "New Tab Redirect!";
$scope.enable_bookmarks = false;
$scope.enable_top = false;
$scope.bookmarks = [];
$scope.show_prefs = false;
$scope.bookmark_count = 10;
$scope.top_count = 10;
$scope.save_preferences = function(){ };
function loadBookmarks() { }
function loadTopSites() { }
function loadApps() { }
$scope.$on('UninstalledApp', loadApps);
// initial page setup
var querySettings = [enable_top_key, enable_bookmarks_key, bookmarks_count_key, top_count_key];
Apps.getSetting(querySettings)
.then(function(settings){
// assign settings to scope
})
.then(function(){
loadApps()
.then(function(){
loadBookmarks();
loadTopSites();
});
})
.then(function setupWatches(){
$scope.$watch('bookmark_count', loadBookmarks);
$scope.$watch('top_count', loadTopSites);
});
}]);
When you declare a Controller, you can pass just a function as the second parameter and the parameter names will tell AngularJS how to look up services, factories, or other injectables so they’re available in your controller. Another way to do this is as I’ve done it and pass an array where the beginning of the array are the names of the dependencies and the last element of the array is the function of the Controller. This style allows you to later minify code without breaking AngularJS’s dependency injector.
You’ll notice here that Apps.getSetting is a Promise. Promises make code way cleaner. The way the getSetting promise is setup here allows me to set all settings to their properties on the scope, then load apps (always done), then conditionally load bookmarks and top sites. After everything is loaded, a $scope.$watch call allows us to say that anytime bookmark_count or top_count changes, call the relevant function again. If I had bound these watch functions anytime before in this promise chain, these functions would be called multiple times. Each function simply delegates to the Apps service call and returns a function, so that code is omitted from the above logic.
services.js
The services file actually contains a single service, Apps. The service has the following interface:
{
getAll: function () { },
launch: function(id){ },
pinned: function(url){ },
newWindow: function(url){ },
uninstall: function(id){ },
tab: function(url){ },
navigate: function(url){ },
topSites: function(){ },
saveSetting: function(obj){ },
getSetting: function(obj) { },
getBookmarksBar: function(limit){}
};
A better design interface would have probably been to create a service facade around the ‘Tabs functionality (pinned, newWindow, tab) and the Config functionality (saveSetting, getSetting). To keep it simple I used only ‘Apps’.
Each of these functions returns a promise to allow for clean chaining of asynchronous functions.
Rather than explain each function in depth, I’ll cover just the first one and you can look at the others on GitHub.
Apps.getAll() will retrieve all apps using the chrome.management.getAll API call provided by chrome:
getAll: function () {
var deferred = $q.defer();
chrome.management.getAll(function (results) {
$rootScope.$apply(function(){
deferred.resolve(results);
});
});
return deferred.promise;
},
The problem here is that AngularJS is only aware of changes on the scope that occur during the digest loop by explicitly applying ‘regular JavaScript’ to the AngularJS internals. This is done with $rootScope.$apply whenever you have some data that you want AngularJS to consider. Chrome doesn’t provide error callbacks on the API because errors are handled within the browser, making it easy for client applications like this to handle logic. A ‘deferred’, created by $q.defer(); is how JavaScript code can promise a future value to callers and is not AngularJS-specific; jquery has deferreds, Kris Kowal has an excellent Promises implementation called q, and versions of the CommonJS Promises proposal is implemented in many other frameworks or utilities.
A deferred object has two states: success and failure. To trigger the success state of a deferred object (which completes the promise successfully), you would call deferred.resolve. To initiate an error, you’d call deferred.reject. You can chain promises by returning a new promise from a chainable function, usually .then(fn).
HTML
I’m going to cheat a little here and show you the HTML before the directives. I’ll only show two snippets of HTML: one contained in main.html and a template.
In main.html you’ll see:
<div class="container app-container clear" ng-class="{'after-bookmarks': enable_bookmarks && bookmarks.length > 0,'populated':apps.length > 0}">
<div><input type="search" ng-model="q.name" ng-show="apps.length > 5" placeholder="Filter apps"></div>
<chrome-app ng-repeat="app in (apps | filter:q)" app="app"></chrome-app>
<div ng-show="(apps | filter:q).length == 0" style="margin:1.5em">No matches found.</div>
<span class="clear"></span>
</div>
This actually has a lot of AngularJS stuff in it. The opening div tag has this weird ng-class attribute in which the content looks like a JSON object. This is one of many built-in AngularJS directives. It applies the class ‘after-bookmarks’ based on the condition in the value of the property at runtime (during a digest loop). This means that any time enable_bookmarks changes, the classList might change from “container app-container clear” to “container app-container clear after-bookmarks”. If the ‘populated’ condition later changes, we’d have “container app-container clear after-bookmarks populated”. Then, the user could disable the bookmarks setting and AngularJS would automatically update the classList to “container app-container clear populated”. There’s no additional work you need to do.
Next, there’s an input type="search" that has an ng-model and ng-show attribute. Usually, something applied to ng-model will represent a property on your $scope object. So, if you had ng-model="favorite.color", and in your controller, you’ve set $scope.favorite = { color: 'blue' }, the value of the text box would read ‘blue’. If you changed the input text from ‘blue’ to ‘red’, you would immediately have the true condition in your controller $scope.favorite.color === 'red'. The ng-show toggles the display:none style of the element based on the condition.
Next, there’s this weird non-standard XML element, <chrome-app ng-repeat="app in (apps | filter:q)" app="app"></chrome-app>. That’s a directive I’ve defined and will discuss later. The attribute, ng-repeat acts as a foreach loop. The value of that attribute says for each value in apps | filter:q, apply app to the ‘app’ attribute of my custom directive, and generate the templated structure. The apps | filter:q syntax is how AngularJS declaratively applies filters (another available application module like a service or factory). The | is what actually applies the filter, the filter:q is how we define what filter to call and what parameter to pass the filter. In standard JavaScript, this might look like:
var apps = [];
var filtered = apps.filter( function filter(q) {
// filter:q logic here.
});
In AngularJS, the filter filter is way more involved.
The <chrome-app></chrome-app> directive will take the ‘app’ object assigned to the ‘app’ attribute (app="app") and apply it to the following template:
<div class="app-icon">
<a href="app.appLaunchUrl" chrome-launch="app.id" chrome-type="app.type" class="app-icon-128">
<img src="{{app.icons|iconsize:128:app}}" title="{{app.name}}"/>
<span class="app-desc">{{app.name}}</span>
</a>
<div class="app-actions">
<a href="app.appLaunchUrl" ng-if="app.type != 'packaged_app'" chrome-pinned="app.id"
title="Open {{app.name}} in a pinned tab"><i class="fa fa-2x fa-thumb-tack"></i></a>
<a href="app.appLaunchUrl" ng-if="app.type != 'packaged_app'" chrome-new-tab="app.id"
title="Open {{app.name}} in a new tab"><i class="fa fa-2x fa-level-up"></i></a>
<a href="app.appLaunchUrl" ng-if="app.type != 'packaged_app'" chrome-new-window="app.id"
title="Open {{app.name}} in a new window"><i class="fa fa-2x fa-external-link"></i></a>
<a href="app.optionsUrl" chrome-options="app.id" ng-if="app.optionsUrl" title="Open options for {{app.name}}"><i
class="fa fa-2x fa-wrench"></i></a>
<a href="#" chrome-uninstall="app.id" title="Uninstall {{app.name}}"><i class="fa fa-2x fa-trash-o"></i></a>
</div>
</div>
The app object is the result object from chrome’s API call.
The new thing in this snippet is the introduction of {{ somePropertyName }}. This is an interpolation in AngularJS. It’s actually not that performant a lot of the time, but for something like title="{{app.name}}" it is usually the only way to dynamically set string contents. Here you see another AngularJS directive, ng-if, which conditionally adds to or removes from the DOM the whole element it’s applied to. Then, you see other custom directives, chrome-pinned, chrome-new-tab, chrome-new-window.
With these examples, you now can understand probably 75% of the code you’d find in AngularJS
directives.js
The last bit to cover is directives. This is my favorite aspect of AngularJS so I’ll try really hard not to ramble on the topic.
AngularJS lets you define directives to run for any attributes, elements, or CSS class names. I don’t generally use the class feature. Directives allow you to hook into the compile phase or the link phase (but not both simultaneously). You can also define a controller or explicitly create a child scope or isolated scope for the given element(s). I like to keep things simple and stick to adding functionality in the link phase.
Here’s an example:
directives.directive('chromePinned', ['$log', 'Apps', function($log, Apps){
return {
// attribute only
restrict: 'A',
scope: {
id: '=chromePinned',
url: '=href'
},
link: function($scope, $element, $attrs) {
if($scope.id){
$element.bind('click', function(e){
e.preventDefault();
Apps.pinned($scope.url)
.then(function(tab){
$log.debug("Opened app id %s in pinned tab #%d", $scope.id, tab.id);
});
});
}
}
};
}]);
The directive here is declared in the same dependency injection style as the controller, where we define the dependency names and function in an array to prevent breaking the injector if the code is ever minified. The directive must return and object that represents a directive definition.
This directive is restricted to only work on attributes (however, restrict:'AEC' would work on attributes, elements, and class names). Defining an object for the scope property creates an isolated scope where id is data-bound to the property of chromePinned (in attribute format it is chrome-pinned‘s value) and url is bound to href. Isolated scopes break the directive out of the scope hierarchy that AngularJS maintains by default. Isolated scopes can take some getting used to, but I think they’re safer and easier to follow.
The linking function binds a click event to the element (e.g. an anchor tag of <a href="#" chrome-pinned="12345">). Any on click, we call Apps.pinned with the url defined by the anchor’s href attribute. Whenever you work on an element in a linking function, you’re working in standard JavaScript (i.e. outside of AngularJS’s digest). You should always call $scope.$apply with whatever function you want to make AngularJS aware of. In this directive, you don’t see that call to apply because it’s done within the service itself.
Conclusion
In all, the new feature was quick and painless to code. The files are clean, easy to read, and well organized.
The code, as always is on github: jimschubert/NewTab-Redirect