Posts tagged firefox

Browser Wars: Learning from each other

0
8 months ago
by Sai Prasad in

The most popular browsers from the country I come from (where Mac is rare) are Google Chrome, Mozilla Firefox & Microsoft Internet Explorer. Like any other browser, these all have the same goal – to make browsing experience richer & better. Yet, there are a lot of differences in their ways and some are better than other in some ways.

If I ever have to make a generic purpose browser, I’d certainly pick good (for inclusion) & bad (for exclusion) things from the current browsers.

Google Chrome:

The recent one and certainly a game changer. It has improved the user expectations from a browser by 100x.

The Good:

  • The crashless browser -  protect the user even from the crashes in external plug-ins (Thankfully, Firefox also implemented out-of-box plugins)
  • Faster startup time – Do things that are only absolutely needed. Nothing more. Defer everything else, to post-startup (in parallel with the user’s browsing).
  • Sandboxing – Whatever you do on web stays on web. Protect the machine from all the various security issues.
  • Explicit permissions listed for Extensions – user must know what an extension is capable of (despite of what it claims to do)
  • Silent updation: Push updates only when it is good for users. Then, who would say “no” to better browsing experience? So, there is no point in showing an annoying dialog “Updates Available” when you already know the user clicks “yes”.
  • Incognito Mode starts a new session without closing the current session (sadly, Firefox does that)

The Bad:

  • Weakest & the most limited extension model – So limited that it may give you a feeling that the word “extension” doesn’t suit it.
  • Still an immature platform for developers. Extension Model hasn’t moved but the other parts (rendering, UI etc.) are moving forward at a very fast pace. Even, many bugs in the chrome extensions are not getting fixed for many months.
Mozilla Firefox

The Good:

  • Super cool extension model. There is almost nothing that can’t be done by the addons. And, XPCOM works across all the platforms.
  • Known to be the developer-friendly browser from long time. One of the early browsers that emphasized on standards and innovation from its early days.

The Bad:

  • Known to be memory hog. Not efficient at Memory management. Have issues with Intel’s hyperthreading.
  • MaxVersion in addons is mandatory and is limited to current version (you can’t just use * for maxversion). The only issue with this is each and every addon is to be updated (you add features or not) with every major version release (which is once in 12 weeks as of now).
  • Private browsing closes the current session and starts a new one. After closing private session, it restores the earlier session. This means you can’t do both (with default command line options)
  • Every extension have complete control (including a binary component), because of lack of a permission model. You can never trust an extension because of this!
Internet Explorer

The Good:

  • Its never late to catch up with the standards, speed & security (with IE 9 & IE 10)
  • Native 64-bit for 64-bit OS. (I can’t believe Firefox and Chrome do not have them for Windows)

The Bad:

  • Still maintains the completely idiotic ‘Quirks Mode’. I don’t see the greater cause of maintaining a version which is full of bugs, extremely slow and follows no standards, and also all developers hate it.
  • Extension Model – Its a big pain. You need to be comfortable with COM to get started with. Its much comfortable to think addons don’t exist at all for this version.
  • Supports ActiveX plugins when the whole world uses NPAPI plugins.

Disclaimer: All the above are my own thoughts, and I’ve to confess I haven’t researched every point. So, not all the above may be true, but is to the best of my knowledge.

Firefox Addons: Little Housekeeping Tips

0
11 months ago
by Sai Prasad in

I’m working on a Firefox addon in the last few weeks and this is my 1st experience with Firefox addons. During my tiny experience, I came across some of those little things that helps you when you’re in trouble & here I’m writing about those simple tips. Of course, I mixed some changes in Gecko 2.0 also along with these….

I know these are very basic, and almost everyone who worked on the addons might be knowing them, but hey, didn’t I mention you that this is my first encounter with building firefox addon?

How can I be sure if a Binary XPCOM component is loaded / attempted to load from Firefox?

Close all Firefox windows and run the following from command line:

set NSPR_LOG_MODULES=all:5
set NSPR_LOG_FILE=c:\ff.log
C:\Program Files\Mozilla Firefox\firefox.exe

What does it do? Line 1 sets the modules to load & the log level. In the above commands, we are asking to log all modules with log level 5 (meaning all logs). Line 2 sets the path to log file. Now, just launch the Firefox from command line (so that the variables are set)

Troubleshooting Tip: Do not use quotes around the log file name, like set NSPR_LOG_FILE=”C:\ff.log”. I tried it the 1st time and it doesn’t work.

References: Troubleshooting XPCOM components registration, NSPR Logging

How can I sure if an XPCOM component is successfully registered?

This works for both binary & JS components.

Enable Chrome errors in Error Console, if you haven’t done already! To enable, set javascript.options.showInConsole to true in about:config preferences.

Open Error Console (Ctrl+Shift+J)

Evaluate Components.classes["components-contract-id"].name. Use with the components’ contract id.

If it gives no error, the component is successfully registered.

References:  javascript.options.showInConsole, Troubleshooting XPCOM components registration

How to log errors from the XPCOM components?

This is simple thing, and I realized a bit late about it. This is currently how I’m debugging my components (need to see if there is a better way). You can report error messages to the Error Console with:

Components.utils.reportError(“This is the description of the error”);

References: Error Console

nsIConsoleService

The inconvenience with the reportError API is that it logs all messages as errors. To log at various levels (debug / warning / info), we can use the nsIConsoleService. The logStringMessage() function of this service looks very handy.

I haven’t used it yet, so I cannot give any more information on this!

References: nsIConsoleService Reference

UnPack option

If you are using binary components in the addon, you MUST set the unpack value to true in install.rdf file.

References: unpack in Install Manifests

Bootstrap Addons

This feature introduced in Gecko 2.0 answers one of my long-time questions – Why should I restart the browser everytime I add / update / disable / remove an addon?

Though this feature is good, it looks complicated to do all the manual work. I’ve skipped trying this feature for now, but I’ll look into this some other time.

References: Bootstrapped Extensions

Gecko 2.0 XPCOM Changes

Though there are many changes, I’m listing the few which I came across.

  • Javascript component must export NSGetFactory() instead of NSGetModule() function. Binary component must export NSModule() instead of NSGetModule() function. I’ve explained this in detail in the next section.
  • Components in components/ folder are no longer auto-registered & auto-loaded. Components registration will be done through the manifest file.
  • Category Registrations are done through manifest file. Also, category names are modified.
  • You’ll have to use the XULRunner SDK 2.0 for Gecko 2.0

Troubleshooting Tip: Use the sample CPP file (from the references) to get started for binary components. I got a few compilation errors initially, and then I has to add MOZ_NO_MOZALLOC to preprocessor definitions as read somewhere, and it worked..

References: XPCOM Changes in Gecko 2.0, nsSampleModule.cpp source code

Component Registration in Firefox 4.0

All the components to be registered has to mentioned in the chrome.manifest file.

  • All the interfaces (xpt files) are to be registered using interfaces command
  • A JS component must use component command. It needs to mention its class id also. The contract id can be assigned to this JS component by a separate contract command.
  • A binary component can be registered with binary-component command. A binary component registration need not specify any class-id or contract-id in the manifest file, since they are available through the exported NSModule() function.

References: Chrome Registration

If you have felt all the content is copied from somewhere, its ok because its true. I’ve learned many things from MDC itself, I’m just aggregating those things here!!

If I’ve got something wrong in here, please do mention them in the comments as I have to correct them in the post as well as in my mind…

 

Troubleshooting XPCOM components registration

 

Go to Top