#crossrider

Avoid the latest fake Flash Player installer for Mac, it’s nasty malware

“Macs are not immune to malware, but they are pretty well-protected. By default, macOS won’t allow unrecognized apps to be installed, and it needs the user to agree to override this,” Ben Lovejoy reports for 9to5Mac. “Even when they are installed, sandboxing limits the damage that can be done, which is why most Mac malware is actually adware – annoying but not damaging.”

“A common way…

How to remove the FlashMall adware from OS X

Anytime you are using your Mac and are suddenly inundated with popups, unwanted Web pages opening, and other ads, then you are likely either using or getting too close to illegitimate resources. Generally this happens when you stumble across a nefarious Web site, but at other times it can be from adware and other malware you have installed on your system. One such instance of this is if you find…

Often extensions employ a remote database for storing/collating data. Setting up and managing such databases can be time consuming, costly, and an undesireable overhead. Google Spreadsheet provides a convenient and flexible JavaScript Service API that can utilize a spreadsheet as a remote database.

This blog walks you through the steps required to create, configure, and code a simple Crossrider extension that counts page visits using a spreadsheet as a database.

Let's start by creating a Google Spreadsheet:

Create a new Spreadsheet in your Google Docs account (Sheets > Create new spreadsheet) and optionally give it a name (e.g. Blog Database).

Add the required column headings (e.g. URL, Count) and format the column cells as plain text (Select the columns > Format > Number > Plain text).

Make a note of the sheet's Alphanumeric ID. You can get the id from the sheet's URL:

In the next step, we add and deploy the sheet's server-side script:

Create the server-side script (Tools > Script editor).

In the editor, add the following code for handling HTTP GET requests (for more information, see Web Apps and Google Sites Gadgets and Spreadsheet Service:

// Global vars var actions = { getUrlCount: getUrlCount, incUrlCount: incUrlCount }, sheetId = '', // Specify the SHEET_ID here data = {}; /** * Handles API requests received via the HTTP GET method/verb * @param {object} request * @return {JSON} res */ function doGet(request) { // return if action is not specified var action = request.parameter.action; if (!action) return ContentService.createTextOutput(JSON.stringify({ action: action, error: 'Missing parameter: action not specified' })) .setMimeType(ContentService.MimeType.JSON); // get URL of visited site and initialize response var url = request.parameter.url, res = { action: action, count: 0 }; // process if action function exists if (typeof actions[action] == "function") { // set sheet information data.sheet = SpreadsheetApp.openById(sheetId).getSheets()[0]; data.cells = data.sheet.getDataRange().getValues(); // set response count res.count = actions[action]("" + url); } return ContentService.createTextOutput(JSON.stringify(res)) .setMimeType(ContentService.MimeType.JSON); } // Helper functions /** * Searches sheet for the row containing the specified * @param {String} url * @return {Number} row */ function findRow(url) { // Iterate through the rows and find matching url for (var i=1; i<data.cells.length; i++) { if (data.cells[i][0] == url) { return i; } } return null; } /** * Gets the URL visits count from sheet * @param {String} url * @return {Number} count */ function getUrlCount(url) { var row=findRow(url); return (row) ? data.cells[row][1] : 0; } /** * Increments visit count for specified url * @param {String} url * @return {Number} count */ function incUrlCount(url) { // Find row containing url var row = findRow(url); // url does not exist, append new row and initialize count to 1 if (!row) { data.sheet.appendRow([url, 1]); return 1; } // url exists // Get current visit count and its sheet cell var count = data.cells[row][1], cell = data.sheet.getRange("B" + (parseInt(row, 10) + 1)); // Increment visit count cell.setValue(++count); return count; }

Deploy the script as a web app (Publish > Deploy as web app) with the following settings:

Execute script as: me

Who has access to the app: Anyone, even anonymous

NOTE: To test each change you make to the script, save the script (File > Save), increment the version (File > Manage versions), and deploy it.

Make a note of the script's Alphanumeric ID. You can get the id from the script's URL:

NOTE: Google Services implements limits on the number of API calls. For more information, see Quotas for Google Services.

Finally, we create a Crossrider extension that uses the deployed web app. The code for this example, is comprised of the following: (a) code for incrementing the page visit count, and (b) code for displaying the current page visit count. The extension simply runs on each page, sends a request to increment the visit count, and then displays a banner showing the global number of page visits for 3 seconds.

Start by creating a new extension (My Extensions > Create New Extension),

and then edit the code (Edit Code > extension.js).

In the editor, add the following code:

appAPI.ready(function($) { // Execuet script API URL without parameters var execUrl = "https://script.google.com/macros/s/SCRIPT_ID/exec"; // Specify the SCRIPT_ID here /** * Defines functions that use the Web App script: * @param {String} action * @return {Number} function(url, onSuccess, onFailure) * - url: url visited. Defaults to current page URL * - onSuccess: callback function if request succeeds * - onFailure: callback function if request fails */ function defineFn (action) { // return if action is not specified if (!action) return; return function (options) { // Set options url = options.url || window.location.href; onSuccess = options.onSuccess || function (){}; onFailure = options.onFailure || function (){}; /** * onSuccessWrapper: wrapper to parse response data * requestUrl: API URL with parameters applied */ var onSuccessWrapper = function (data) { try { onSuccess(appAPI.JSON.parse(data)); } catch (e) { onSuccess(null); } }, requestUrl = execUrl + "?action=" + action + "&url=" + url; // Make GET request appAPI.request.get({ url: requestUrl, onSuccess: onSuccessWrapper, onFailure: onFailure }); }; } // Define increment visit count function var incUrlCount = defineFn("incUrlCount"); // Optional: Define get visit count function //var getUrlCount = defineFn("getUrlCount"); // Inject notification HTML into page $('') .css({ 'background-color':'#000', 'color':'#fff', 'font-size':'12px', 'height':'20px', 'line-height':'20px', 'position':'fixed', 'text-align':'center', 'top':'-20px', // Hide notification 'width':'100%', 'z-index':'99999' }) .appendTo('body'); // Increment the page visit count and then display notification incUrlCount({ url: location.origin + location.pathname, // current page URL onSuccess: function(response) { if (response.count) { // Display notification if increment succeeded $('body').animate({'margin-top': ['20px', 'swing']}); $('#gsdb-demo') .html('This page has been visited '+response.count+' time'+((response.count!==1)?'s':'')) .animate({'top': [0, 'swing']}); appAPI.setTimeout(function() { $('body').animate({'margin-top': [0, 'swing']}); $('#gsdb-demo').animate({'top': ['-20px', 'swing']}); }, 3000); } } }); });

It’s that simple and a significant step forward in developing extensions using remote databases. Give it a try, feel free to improve the code, and see for yourself just how easy it is to use our platform.

Finally, you are invited to try our Google Spreadsheet demo extension and rise to the challenge of making your own cool extensions. Get started quickly by cloning the demo extension (Edit Code > Clone This Extn).

Messages come in many forms, contexts, and architectures and when writing extensions, it's often necessary to pass information between scopes. This can be for many reason such as information that's only available in one scope (e.g. only the extension scope has access to the page HTML, or the background scope having access to browser bookmarks), and you want to pass it to another scope.

The information can be shared either passively via the extension's local storage (appAPI.db.async) or actively via the messaging (appAPI.message) mechanism. Furthermore, the exchange of information can be unidirectional (one-way) or bidirectional (two-way), but regardless of the scopes and the directions involved, the mechanism is same.

Note: When choosing an appropriate mechanism, it's worth considering the relative pros and cons of each method. For example, sharing a large amount of data via messaging may present performance issues and limitation (e.g. Internet Explorer is limited to 8KB per message) whilst sharing via the local database lacks immediacy.

The process for sharing via messaging is simple, one scope initiates the sending of a message and, as long as the receiving scope has a listener to receive the message, the massage passes from the sender to the receiver.

Unidirectional

For example, let's take the following unidirectional scenario where the extension scope wants to pass the page title to the background scope, so that the background scope can use it to add the page as a browser bookmark (appAPI.bookmarks):

extension.js:

appAPI.ready(function($) { // Send message to background scope appAPI.message.toBackground({ request: 'save-bookmark', url: window.location.href, title: $('title').text() }); });

background.js:

// Make sure bookmark plugin is added to extension appAPI.ready(function($) { // Message listener to receive messages from any scope appAPI.message.addListener(function(msg) { if (msg.request === 'save-bookmark') appAPI.bookmarks.getDefaultFolder(function(node) { appAPI.bookmarks.create({ title: msg.title, url: msg.url, parentFolder: node }); }); }); });

Bidirectional

Often, a bidirectional communication is required and is implemented in the same manner as the unidirectional example, except that senders and listeners are added to both scopes as required. Take the following example, where the popup scope requires the page URL. The popup scope itself cannot directly access this information, but the extension scope can. In this scenario, the popup scope initiates the bidirectional communication by sending a message to the extension scope requesting the page URL, and then the extension scope responds with the information.

extension.js:

appAPI.ready(function($) { // Message listener to receive messages from any scope appAPI.message.addListener(function(msg) { if (msg.request === 'get-page-url') // Send information to popup appAPI.message.toPopup({ request: 'get-page-url', url: window.location.href }); }); });

background.js:

// Make sure bookmark plugin is added to extension appAPI.ready(function($) { // Message listener to receive messages from any scope appAPI.message.addListener(function(msg) { if (msg.request === 'get-page-url') console.log('Received page URL:'+msg.url); }); // Initiate request for page URL appAPI.message.toActiveTab({ request: 'get-page-url' }); });

Between Iframe and Parent Window

You can even use messaging to communicate between an iframe and the page that contains it. For example, if an extension needs to know the URL of iframes that are ready, the instance of the extension scope running in an iframe can send a message to the instance of the extension scope running in its parent page.

Let's take a moment to understand how this works. An instance of the extension.js code runs in the scope of the parent page and another completely independent instance runs in the iframe. However, they are both using the same extension.js file. So how does each scope know what code it needs to run? We distinguish between the code for each scope using appAPI.dom.isIframe, like in the following example:

extension.js:

// Make sure to enable: Settings > Run in iframes appAPI.ready(function ($) { if (appAPI.dom.isIframe()) { // Code run in iframe appAPI.message.toCurrentTabWindow({ request: 'report-url', url: window.location.href }); return; } // Code run in iframe parent window appAPI.message.addListener(function(msg) { if (msg.request === 'report-url') console.log('Iframe ready:: URL: '+msg.url); }); });

Unified Listener

Of course, it isn't necessary or recommended to add a separate listener to receive messages for each scope, a single listener for all scope is sufficient and more efficient. Taking the examples above, in the extension.js code we can have a single listener to handles all the different requests. For example, we can combine the previous 2 examples (the popup and iframe listeners) as follows:

extension.js:

// Make sure Settings > Run in Iframes is enabled appAPI.ready(function ($) { if (appAPI.dom.isIframe()) { // Code run in iframe appAPI.message.toCurrentTabWindow({ request: 'report-url', url: window.location.href }); return; } // Code run in iframe parent window appAPI.message.addListener(function(msg) { // iframe listener if (msg.request === 'report-url') console.log('Iframe ready:: URL: '+msg.url); // popup listener else if (msg.request === 'get-page-url') // Send information to popup appAPI.message.toPopup({ request: 'get-page-url', url: window.location.href }); }); });

Sharing Large Data

Finally, you can share large data using a combination of messaging and the local database, as follows:

extension.js:

appAPI.ready(function($) { // Message listener to receive messages from any scope appAPI.message.addListener(function(msg) { if (msg.request === 'get-large-data') // Get data from local database and use appAPI.db.async.get('large-data', function(value) { console.log('Got large data: ', value); }); }); // Request the background scope to retrieve data from a remote site appAPI.message.toBackground({ request: 'get-large-data', url: 'http://example.com/largedata.php' }); });

background.js:

appAPI.ready(function($) { // Message listener to receive messages from any scope appAPI.message.addListener(function(msg) { if (msg.request === 'get-large-data') { // Initiate request for large data appAPI.db.async.setFromRemote( msg.url, "large-data", appAPI.time.minutesFromNow(10), function(response) { // Send trigger to extension scope to handle data appAPI.message.toActiveTab({ request: 'get-large-data' }); } ); } }); });

It’s that simple and a step forward in sharing data between scopes. Give it a try, feel free to improve the code, and see for yourself just how easy it is to use our platform.

If you are not already a Crossrider developer, click the following link to join our cross-browser extension development framework.

Celebrating their 10th anniversary, Mozilla launches Firefox Developer Edition thus replacing its Aurora channel.

Focusing on the developer workflow, the Developer Edition brings together new and existing tools to complement your building, designing, testing efforts and much more. Simply put, all your favorite dev tools under one roof.

The tools highlighted in this nascent release include:

 Inspector for examining a web page's HTML and CSS and modify using the enhanced IDE

 Web Console for viewing page related information logged to the console. Use JavaScript and jQuery directly from the console

 Debugger to step through code and set breakpoint such as clicking on a button in the page

 Style Editor for easily testing and creating CSS and saving the modifications

 Network for monitoring and measuring requests the browser makes in the process of loading a page

 Responsive Design View shows you how a page will look without having to change the browser window size

Web Audio Editor for inspecting and interacting with connected page audio in real time

Valence for developing and debugging apps across multiple devices

WebIDE for developing Firefox OS apps

Learn more and start using Firefox Developer today.

We hope you will find this new addition to the Mozilla family useful, especially the dev tools in rapidly debugging your extensions.Give it a try and share your experiences by commenting on this post.

One of the greatest frustrations with developing extensions is the lack of professional debugging tools like those integrated into Visual Studio. A friendly interface for step-by-step debugging of extension code is simply missing. Instead, we are left at the mercy of the tools provided by each browsers and third party add-ons such as Firebug.

So what's the best way to go about debugging your extensions. What tips can we give you to help you along the way? This blog provides some basic debugging techniques used by our support team. They are easy to implement and we encourage you to use them in your development cycle. If you have any ideas, share them by commenting on this post.

Picture the following scene (we've all been there and will probably end up there again at some point). You created an extension and it's simply not working. For days you've been pulling out what little hair you have left and banging your head on the computer desk.

In many such cases, the first thing you do is call for help by opening a support ticket. This is great and to be encouraged, but there is no reason why you can't debug yourself. In fact, it helps you to understand how to improve your code. The biggest problem is usually identifying the source of the problem, and this can sometimes be tricky due to knock on effects from earlier code. All too often our support receives a ticket that starts "XYZ API is not working" when in reality it's something else that's not working.

How do you identify the source of a issue? We recommend using some or all of the following techniques to identify and resolve the problem:

Test, Test, and Test Some More

Right from the outset, write code in small incremental steps and test each step as you create them. This may seem obvious, but it really helps you identify the source of an issue quickly as it's likely to be the last bit of code you wrote. Our Debug Mode is perfect for this as you can test the code in real-time. What you don't want to do is write the whole extension and then start testing!!

Use Well-placed, Meaningful Console Messages

This tip alone has helped solve hundreds of support cases as it provides a trace similar to a Call Stack. It helps you to understand the flow of your extension execution and identify the section of code where a problem exists; hence, placing these in your code as you write it makes finding the problem really easy.

Make sure messages are:

Well-placed: You can never have too many log messages (well, maybe you can) but at the very least we recommend placing them at the start of key functions and control flow statements.

Meaningful: Strings are nice, but variables often affect the flow of your code. Therefore, add relevant variables and parameters to you messages to give you a better insight into what is causing an issue. If the variable is an object, use appAPI.JSON.stringify to convert it to a string since not all browsers can display the contents of an object.

Personally, we like to add context to the messages including the scope and calling function in the format "<Scope>::<Function>:<Message>". For example:

console.log('BG::appAPI.ready:DB value - '+appAPI.JSON.stringify(oValue));

For information about viewing console log messages in the different browsers, see How to view console messages.

Use debugger

For browsers that support the JavaScript debugger statement (Chrome is great for this), add them to your code and use the browser's Dev Tools Debugger to step through your code and identify an issue. What's more, you can conveniently set them using our IDE's Edit Code page. Simply click on the line number by the code you want to debug and debugger will be added to the code.

Test Suspected Problems in a Simplified Extension

If you suspect a problem with a specific method, test the method in a simplified extension. For example, the support team has occasionally received bug reports identifying the appAPI.request or appAPI.message API as not working in the popup scope. Creating a simplified extension which only opens a popup and uses the suspected API revealed that the API was functioning correctly. This enabled the developer to then check the rest of the code using the next technique and eventually identify the real problem.

Divide and Conquer Commenting

If you have identified a specific function or section of code where the problem appears to exist but don't know which specific line is causing the problem, try commenting out segments of the code until you identify the specific code that's causing the problem. A simple way to do this, is to comment out approx half the code. Test again and If the problem still exists, repeat the process with the remaining code. If the problem is gone, then uncomment half the previously commented code and try again. Continue like this until you identify the problem.

Try-Catch Blocks

As an alternative to the previous technique, but not always as reliable, try wrapping the suspected code in a try-catch statement.

Of course, if you still can't identify the problem you can always contact our support team with as much of the following details as possible and we will be happy to assist:

The extension id

The file/line number where the code snippet can be found

Which browser and operating system you are testing on including version numbers

The exact steps for reproducing the problem

Any additional useful data, such as URLs, screenshots, videos, ...

Providing the requested information is important as it help us to understand and solve your issues faster.

So now that you’re empowered, give it a try and see for yourself just how easy it is to debug an extension.

Many times we are asked to add a new feature or parameter to a core Crossrider API. As much as we'd love to do make all of these additions, it is not always possible and may also take some time to implement.

Often we are busy building key roadmap features or keeping ahead of the fast-paced browser release schedule to make sure your extension just keep on working.

So we'd like to empower you with how to implement some of your requests yourselves. When we built our API, we had you in mind and so we developed our API in JavaScript making it easily to be extended, meaning you can supplement it with your own code to customize it to your own needs.

Let's take the example of a recent request we received from one of the developers in our community. They asked if we could modify the appAPI.request.get onFailure callback function to also take the original Requesting URL as a parameter. (now's a good time to review the method).

Now, it's not particularly difficult to implement, but it is a lengthy process as we must ensure it's worthy of release:

The product team has to review and approve the feature.

A spec is created and the dev team implements the code changes for all supported browsers in the dev environment, making sure it doesn't break any existing code and maintains backward compatibility.

The new method is then scheduled for QA testing, again on all supported browsers, and if necessary the extension is sent back for further changes and the second iteration begins.

Only once QA has given its blessing, which is no mean task given how rigorously we test our API, the method is scheduled for inclusion in the next release cycle.

So the bottom line is that it's not going to happen quickly! This is exactly the case for a developer to extend the core Crossrider API and to share their innovation with the rest of the community.

So what is actually involved in extending the Crossrider API to add the requesting URL to the onFailure callback?

It's a lot simpler than you think! In the following example, we use a high order function and IIFE to create a private scope for extending the appAPI.request.get method.

// Defensive semicolon ; appAPI.request.get = (function() { /* Save a reference to the original function inside * a "private" scope using the IIFE closure */ var origRequestGet = appAPI.request.get; // Return the extended request method return function(requestDetails) { /* Save a reference to the extended onFailure callback function. * Save it inside a "private" scope using the closure */ var origOnFailure = requestDetails.onFailure; // Redefine the referenced onFailure callback function // using the original request method parameters requestDetails.onFailure = function(httpCode) { /* When callback is invoked, call the extended * onFailure callback function adding the url * details passed to the request */ origOnFailure(httpCode, requestDetails.url); } /* Call original request method with the details passed * to the request */ origRequestGet.call(appAPI.request, requestDetails); } }());

Another, slightly more complex example is a request we received asking for a deferred promise to be added to the appAPI.db.async and appAPI.request methods. To implement this as an extension to the existing API methods, we made use of the jQuery promise feature as you can see in the following github code.

So now that you're empowered, give it a try and see for yourself just how easy it is to extend the Crossrider API. Of course, please feel free to share your innovations with the Crossrider developers community (click Share an idea) for the benefit of others.

If you are not already a Crossrider developer, click the following link to join our cross-browser extension development framework.

At Crossrider, we support the initiatives for a greener and better world.

Though you might not really save the world from global warming using this extension, it does give some ideas on how the right code can actually makes electricity consumption more efficient.

Even if it is a small change, on a large scale, it does matter!

As you already know, the brighter a screen is, the more electricity it uses, so this is why we’ve created a simple yet effective browser extension that acts as a screensaver that you can easily incorporate into your extensions code as well. 

The screensaver monitors activity in the browser and fades the tab content when none is detected for a period of time, 10 seconds for the purpose of this demonstration.

Once activity is resumed, the screen saver is removed and the browser returns to you.

So let’s get started by creating a new extension (My Extensions > Create New Extension),

and then heading over to edit the code (Edit Code > extension.js).

For this extension, we will create a resource file to store our CSS and code in the Extension Page Scope (extension.js). First, let’s add the CSS resource file (style.css) and add the following CSS for styling the element used for fading the tab content.

#x-green-saver { background-color:#000000; border:none; border-radius:0; height:100%; left:0; margin:0; opacity:0; padding:0; position:fixed; top:0; width:100%; z-index:-9999; } #x-green-saver.enabled { z-index:99999; } #x-green-saver p { color:#444; font-family: Rockwell, Georgia, "Times New Roman", Times, serif; font-size: 18px; position:fixed; right:20px; text-shadow: 0 1px 0 #666; top:20px; }

Next, we’ll add the code that manages the screensaver functionality using the following top-level algorithm:

Inject the CSS rules in style.css to the page being viewed (uses appAPI.resource.includeCSS)

Inject the div used for dimming the tab content

Use jQuery to add an event handler for detecting activity in the browser and resetting screen saver

Add the interval check to determine whether to fade the tab content (uses appAPI.setInterval, Crossrider’s cross browser setInterval method)

Add a helper function that generates the text for showing the elapsed time on the screen saver

The finished code looks like this:

appAPI.ready(function($) { var Timeout = 10, // default timeout before screensaver is activated _counter = 0, // counts elapsed inactivity in seconds _enabled = false; // screensaver status // Inject the CCS rules in style.css to the page being viewed appAPI.resources.includeCSS("style.css"); // Inject the div used for dimming the tab content $('<div id="x-green-saver"><p>Last activity: <span></span> ago</p></div>') .appendTo('body'); // Use jQuery to add an event handler for detecting activity in the browser and resetting screen saver $(document) .on('click mousemove keypress', function() { // checks activity of mouse and keyboard _counter = 0; // resets the counter if (_enabled) { // resets the content fade if active $('#x-green-saver') .animate({opacity: 0}, 500) .removeClass('enabled'); _enabled = false; } }); // Add the interval check to determine whether to fade the tab content appAPI.setInterval(function() { if (++_counter >= Timeout) { // If no activity is detected for Timeout seconds if (!_enabled) { // Activate the screensaver if it’s not currently active $('#x-green-saver') .addClass('enabled') .animate({opacity: 0.95}, 1000); _enabled = true; } $('#x-green-saver span').text(counterText(_counter)); } }, 1000); // Add a helper function that generates the text for showing the elapsed time on the screen saver function counterText(sTime) { var sec_num = parseInt(sTime, 10), hours = Math.floor(sec_num / 3600), minutes = Math.floor((sec_num - (hours * 3600)) / 60), seconds = sec_num - (hours * 3600) - (minutes * 60); return ((hours) ? hours + ((hours === 1) ? ' hour ' : ' hours ') : '') + ((minutes) ? minutes + ((minutes === 1) ? ' minute ' : ' minutes ') : '') + seconds + ((seconds === 1) ? ' second' : ' seconds'); } });

It’s that simple and a step forward in developing greener extensions. Give it a try, feel free to improve the code, and see for yourself just how easy it is to use our platform.

Finally, you are invited to try our Green Saver demo extension and rise to the challenge of making your own cool page action extensions. Get started quickly by cloning the demo extension. Edit Code >