What is the "architecture" that provides functionality to application-level URI interfaces, like chrome:// and Firefox's about:config, etc?

Question

According to Wikipedia,

about is an internal URI scheme (also known as a "URL scheme" or, erroneously, "protocol") in various web browsers to display certain built-in functions. It is not an officially registered scheme, and has no standard syntax.

my question is... what "powers" these "interfaces"? there doesn't seem to be any kind of "application server" running - that would conventionally support such a front-end - were it to be running remotely.. i'm sure the reason for the dearth of information out there - is that these all break the psuedo-promise that anything "you do" in the browser - won't "effect" your system. these interfaces clearly have access to system level resources and permissions, etc.. are they all simply custom, c-coded hooks to the internal code of the parent applications - or are they a more abstract, ui--layer?

i admit to little knowledge of plug-in authoring, but can this type of functionality be achieved via the typical plug-in API's, or are they too limited? i have spent some time in the webkit source code poking around - but it is so massive and convoluted that its hard to deduct much...

it would seem that however these vendors are implementing these features might be an appealing alternative to say, the various language-specific bridges that webkit implements on various platforms. i personally find the bridges frustrating, which is probably what led me down this train of thought...

any insights appreciated.

Answer 1

A modern browser has to support a number of different URI schemes, e.g. http:, ftp:, file:, data:, mailto:. The handling can be very different depending on the scheme, it isn't always about communicating with a server - data: gets the data from the URI itself while mailto: simply opens an external application (or sometimes a web page). So AFAIK each browser uses different protocol handlers for each URI scheme and these protocol handlers can do just about anything.

The chrome: protocol in Firefox is a way to access the chrome registry. The browser and extensions register the location of their "servers" for their chrome "servers", these locations are either a directory on disk or a directory inside a JAR (technically: ZIP) file. The protocol handler uses the data from the registry to resolve chrome: URIs into the equivalent file: and jar: URIs. There is some additional magic related to considering the current locale/skin but that's about it. The hard work (actually getting the data) is then performed by the handlers of the file: and jar: protocols.

The about: protocol in Firefox also doesn't do any work by itself. The word following about: determines which handler the protocol handler needs to use. It will look up this handler in XPCOM and let it do the work. Most handlers will again defer the work to other protocols - the about: URIs are usually just shortcuts. For example, about:config is simply an alias for chrome://global/content/config.xul.

I hope that this gives you an idea of how this architecture works - there is no big handler for every kind of URI, the work is rather distributed over many components. XPCOM is the glue holding these components together and making sure that components can come and go (e.g. via extensions) without everything breaking apart.

Answer 2

about: is really nothing more than an if statement somewhere in the browser code -- a special case that does whatever the browser programmers want it to do. There's nothing special about it.

Even though a browser's main task is to render web pages, it's still just an application that can do other things as well.

Answer 3

As already said in two previous answers, those are not real schemes with system hooks, but just a browser feature which responds to some types of addresses.

I just want to add that there is a simple way to figure it out:

• If it was a real scheme or a hook, it would work in any browser.

  1. Open Chrome.
  2. Open Internet Explorer.
  3. Open chrome://settings/ in IE.

  You see a 404 instead of Chrome Settings. A scheme or hook is not intended to behave like this: it is expected to work for any browser, either by showing something, like http://, or by redirecting the user to an external application, like ed2k://, or by showing an error message, like unexistent://.

• If it was a real scheme, it would be registered. In Windows, for example, this means that there would be a registry key in a specific place for this scheme.

these all break the psuedo-promise that anything "you do" in the browser - won't "effect" your system. these interfaces clearly have access to system level resources and permissions

What makes you think so? In Windows, an URL scheme is just a registry key. If Chrome registered the chrome:// scheme, a call to chrome://hello/world would call an instance of chrome.exe, passing hello/world as an argument. Yes, installation of Chrome affected your system by adding another registry key, but any installation of any software affects your system. Browser sandbox model remains active: it's not by calling a registered scheme that you'll break something (well, you can, and to avoid this, browsers ask you to confirm what you're doing when using a new scheme for the first time).

Answer 4

Firefox's about:config appears to be a UI for editing the prefs.js file.

There are three methods: pref(), user_pref(), and lock_pref() that can be used in JavaScript. Probably not from JavaScript in web pages, for obvious security reasons, but instead in XUL / .XPI packages.

At the first link above it says:

Distributors can add default preference files via .XPI packages.

and it gives sample install.js code.