1

We are currently developing a Chrome browser extension that inserts our content and controls into specific external websites for users to interact with via Chrome's 'content script' sandbox. We have it working very well. However, we have TWO concerns:

  1. Needless to say, we rely heavily on the HTML structure and DOM ids in these external websites where we insert our own controls and content. As such, sometimes the websites changes minor things around and we have been able to react rapidly. The question is: how vulnerable are we? The external websites have the same JS dependencies on these DOM ids and HTML structures as we do. We reckon, they will be loathe to change things around significantly unless there is a total website overhaul. Thoughts?

  2. As we continue to augment our Chrome browser extension we are trying to avoid native Chrome API calls as much as we can. However, as we move from content script development to the Chrome's 'background', we see the high chance that we have to resort to native Chrome API calls--especially as messages are sent between the background and the content scripts. We're abstracting the Chrome calls for now and plan to replace them with Firefox APIs. Aside from this standard practice, with an eye on moving on to Firefox soon, are there ways to mitigate or eliminate the impact of modifying the extension from Chrome to Firefox? In other words, aside from routine software development best practices, are there best practices specific to developing cross-browser extensions?

Thoughts and links are greatly appreciated.

MoMo
  • 1,836
  • 1
  • 21
  • 38
  • i think best practice applies to all. lazy load stuff as much as possible. keep memory low. etc basic stuff – Noitidart Feb 25 '14 at 07:06

1 Answers1

0
  1. When you integrate too tightly in a website, your extension (or the website) could break due to conflicts (with other extensions). Try to minimize the number of dependencies on the specific structure of a web page and provide fallbacks where possible.
    Keep track of the relevant elements and check whether they still exist in the document (with (automated) (integration) tests).
  2. Abstract away the platform-specific details in separate modules, and make all methods asynchronous. It is easy to use a synchronous (extension) API in an asynchronous method, but not the other way around.
    Some APIs are really platform-specific. Instead of writing an abstraction for these APIs, develop platform-specific modules that provides the functionality you want.

If you want to read more about my 2c on testing browser extensions, see Testing browser extensions.

Community
  • 1
  • 1
Rob W
  • 341,306
  • 83
  • 791
  • 678