Firefox/Feature Brainstorming:Add-ons, Platform Development

Extensions </dt>

• Finally codify and document all existing interfaces: chrome, DOM, XPCOM before inventing new ones.
• Make it easier to write extensions (new sandbox for extensions, extension platform?)
• Allow for limited types of sandboxes that bypass security by strongly limiting extension abilities.
  • Simple toolbar and toolbar button extensions which can only do anything when clicked and only do a limited number of things (make some HTTP request, change the location, open a window or tab, etc.) and can't do anything otherwise.
  • Similar menu operations
  • Extensions that auto-install and then show a permissions dialog.
    • Enable/Disable reading or writing clipboard
    • Enable/Disable reading or writing current DOM
    • etc.
  • Most important, you could install these without trusting the sources. Special link elements or HTTP headers could even associate pages with special extensions to autoinstall and enable just while at the given page.
• Provide a simpler API for functionality extensions commonly use, including:
  • accessing preferences
  • filesystem operations (f.e. rginda's <a href="http://lxr.mozilla.org/mozilla/source/extensions/irc/js/lib/file-utils.js">file utils library</a>)
  • observing onLocationChange (i.e. getting notified whenever the page changes)
• Provide support for hierarchical extension dependencies
• Extension preferences export, sort of like an OPML for extensions that can get slurped in to another FF seat
• Include Thunderbird in Firefox, like Sunbird was added to Thunderbird. ( guess you should use SeaMonkey !)
• add a system to be able to choose what handle what in firefox (firefox built-in svg instead of an external SVG plugin for instance)
• add a generic plugin like plugger so you are able to choose depending on a mime/type or file extension a program to handle it inside an html page.
• allow extensions to expose individual buttons instead of toolbars, and allow buttons to be placed using "Customize Toolbar". This would allow individual features from different extensions (I.E. Google PageRank and Web Developer toolbar cache disabling) to be used without using the entire toolbar.
• allow extensions access to content displayed by plugins. For example, I'd like to be able to mark up PDF files with the ScrapBook extension.
  • If Firefox and Thunderbird are integrated, please keep standalone versions of each available to download. Then users who only require one of the programs can still use it without wasting resources. Better yet, keep them separate.

Platform

• "Compatibility mode" - if an add-on doesn't work under the most recent version/alpha/beta then the user can choose to have Firefox run the add-on as if said add-on were being run under the latest compatible version.

• A useable security model for remote XUL. Currently the restrictions on remote XUL cripple many possible uses for the platform, and there is no easy way to elevate the permissions for a remote application or domain.

n/a

Custom protocol support </dt>

• Allow registration of Firefox as the handler for extension-defined URL schemes and/or MIME types.
• Allow registration of about:whatever XUL pages.
• Implement and/or document some means of reading an external binary file (probably a remote one) and writing the data (probably somewhat altered/filtered) to a channel, assigning an arbitrary MIME to that channel, and returning the channel from within newChannel(aURI) function of <a href="http://www.nexgenmedia.net/docs/protocol/">Rosenberg code</a> and alike. Possible applications:
  • Converting remote WBMP to BMP (see wmlbrowser extension)
  • Any other form of supporting a previously unknown file type by the means of XPCOM instead of NS plugin
  • Image filtration, e.g. contrast masks for visually impaired users
• Support some means for a <a href="http://www.nexgenmedia.net/docs/protocol/">Rosenberg code</a>-alike newChannel() to determine whether aURL designates on object embedded in a larger page (e.g. designates an image/object inside HTML) or displayed by itself. Possible appications:
  • XUL wrapper for any image that is displayed by itself (not embedded), implementing a table set beside that image: EXIF data, width/height/size/whatever hints...
  • In case of error, simple broken image if embedded, but detailed XUL error messages for an image intended to be displayed by itself.
  • For a cache of p2p-hosted objects, if an object is not (completely) downloaded yet, broken image on a larger HTML page, but detailed XUL info+controls for the image address.
• If <a href="http://www.nexgenmedia.net/docs/protocol/">Rosenberg code</a> defines an URL scheme via return ios.newChannel("chrome://.../some/picture.png", null, null), then the defined scheme (and not chrome://) should appear in image properties, and after View Image context click, and in other similar address fields.

• <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=340333">bug 340333</a>
• <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=55659">bug 55659</a>

Icon management support </dt>

When a file:// address is added to Firefox bookmarks, then the browser gets a file icon (presumably from the OS) and the icon is displayed beside the corresponing bookmark, even if the file is some DLL or MS Word document. However, when you browse the directory via file:// address, there are no such proper icons for files, only in bookmarks they are supported.

• First of all, this is a bug (directory view lacks existing features, uniform white sheets are used for most of file types unknown to Firefox).
• There should be an XPCOM to allow JavaScript importing of icons for system file types, and for importing of icons from icon library files (DLL, ICL, ICO).
• There should be some means of displaying such images inside the browser/XUL chrome.
• Possible applications:
  • When a FlashGot-alike extension prompts its user to choose an external download manager, the icon of such manager could be imported from the file returned by nsIFilePicker, and displayed inside the prefwindow.
  • If someone writes an extension equivalent to Total Commander, what means could be used to get icons for/from the files on a file manager pane/tab?

n/a

APIs </dt>

• Add a metadata handler extension API
• SHA-2 hashes and AES-256 or other strong crypto in JavaScript (operate over base64 or binhex). Good for AJAX securty.

Pages with wrong/unknown mime type </dt>

• Often I will find a page that firefox can't display. Nearly always, such pages are plain ASCII text with a weird mime type. For example, firefox doesn't know how to display typical source code. (C, FORTRAN, BASIC, Pascal...) I get a dialog asking me to save the file to disk or choose an app for displaying the file. One particularly desirable display choice is missing: the browser itself!!! Come on now, it's plain ASCII text. Surely the browser can handle this.
• Firefox can determine the mime type of a local file. (by magic or extension I suppose) For remote files, it always blindly trusts the server. Nearly always, the server just looks at the file magic or extension. This ought to not matter, but it does. Servers often lack a complete and modern mapping from extension/magic to mime type because people don't often install lots of multimedia apps on servers. Such servers will substitute a generic mime type. IE tolerates this just fine because IE determines mime type from the file extension alone. Firefox acts weird: if you "save link as..." and then view the local file, firefox will use a different (inconsistant) mime type. At the very least, IE-like behavior should be an option, and should always be used when the server-provided mime type is clearly useless. If firefox must pop up a dialog to ask the user about viewer apps, the default needs to be that of the file extension. Probably it is better to just bury this server-knows-best relic of the past though, standard or not.

Javascript improvements </dt>

• Library improvements
  • Javascript function for DNS queries (something like "function queryDNS(string FQDN, string RR-type)" which returns an array object of the records). We want to write a GPL'ed Firefox Extension providing a global DNS-based addressbook to the Firefox users. But as JS can't do DNS queries, we would have to use some kind of Java or C/C++ for the DNS queries which in turn would increase (platform) dependencies. And no, we won't use a webservice for the DNS queries because of load, scalability and reliability.
  • Put atleast one of the most commonly used Javascript libraries in the browser (scriptaculous, etc) so users don't have to keep downloading them.
  • Bundle popular javascript frameworks like Scriptaculous, YUI, EXTJS with Firefox
  • Throw in the Ruby interpreter and use its rich libraries.
• Interpreter improvements
  • Include a step-through javascript debugger (or possibly include this in the Javascript Console).
  • Create a JavaScript Compiler (for developers) and decompiler (for the Interpreter), basically to allow small sizes for .js files (creating javascript compiled .jsc files), and maybe it could be a good method to speed up javascript code.
  • Real Multi-threading ( make the thread manager available on DOM )

• Javascript Immediate Window
  • Add an Immediate Window to the Javascript Console (similar to the immediate window in Microsoft Visual Studio), that will allow you to dynamically view and change all javascript variables currently dimensioned on the page. Possibly a list of functions and/or methods that you can double-click to execute (and if it returns a value, it could present it in a messagebox or tab or something...) Also, if you could inject html and/or javascript method/functions into the page, it could be very useful for obvious debugging purposes.
  • Maybe a right-click + "Insert HTML here" contextual menu item.

<a href="https://wiki.mozilla.org/User_talk:Jkulkarn">Bundle javascript frameworks with firefox</a>

Netscape Plugins </dt>

• There should be a possibility to control the volume of Plugins such as flash or java. There are few things that are more annying than flash animations that make noises which you don't want them to make.

Architecture </dt>

• Firefox should become a minimal browser
  • All features are provided by the plugin architecture
    • Even basic functions like bookmark manager or history should be provided as extensions to become exchangable
    • Extensions can be installed/uninstalled without restarting the browser
    • Per-machine extensions, Per-user extensions
    • Search plugins are provided as extensions
  • Even the rendering engine becomes exchangable and configurable
    • Support for Gecko, Opera, KHTML, (IE)
    • per-site configurable which engine to use

Developer focus should not be on features, but on architecture </dt>

Firefox should be distributed as package including the core browser plus a set of selected basic extensions like history and bookmark manager </dt>

JavaScript Frame Sandbox </dt>

• Have a way to mark the security level of a frame, for example - say you're writing a web app and you have a frame where you need to display a user uploaded web page - it would be great if you could prevent that frame from accessing it's parent, the cookie, etc. This would make it a lot easier to write a secure web app. AFAIK, the only way to do this is to give that frame a different subdomain - not always a convenient thing to do. Not sure exactly how to accomplish this while sticking to html standards ... any ideas?

Add an Element to HTML Forms: grid </dt>

• Add a grid element to HTML forms to allow for the placement of spreadsheet-like grids in web pages. This would be another HTML form element to go along with texts, passwords, textareas, checkboxes, radio buttons, and select lists. To send the grid as a CGI variable, the lines can be separated by "\n" and cells by "\t". The same characters can be used to set values for the grid when building web pages. The same characters can also be used when copying and pasting as text.

Be able to cancel onBlur events </dt>

• when validating an input field, if we don't want to move into the next field until value is valid we can set focus back to the element, however within that timeframe it may have triggered unwanted events in the adjacent element like onFocus and onBlur, given validation in two fields it would cause a recursive focus jump between the two fields. Having an effective method to handle validation would contribute to more robust web applications.

• Improve RDF support, or develop a better general-purpose data model
• Improve support for multithreading
• Implement more consistent data types ("Instead of JS + variant, mozStorage, RDF, etc. have universal data types (string, integer, decimal, date, blob) that are used everywhere")
• Improve support for advanced UI features like notification icons, alert bubbles, shell integration

n/a

Freezing ABI </dt>

After we compiled xulrunner 1.9a3 and rebuilt our xul application against its libraries, all idl-derived @UNFROZEN interfaces are perfectly available. The xpcom interfaces are c++ classes with no data and only pure virtual members. Member calls use offset of a class pointer, not symbols. So it doesn't matter whether they are exported or not, as long as nsComponentManagerImpl provide those pointers. The former xulrunner was 1.8.0.11, which is several _years_ older than the latter. This underlines tremendous resilience of the XPCOM.

The current mantra of XPCOM usage is "DON'T ever use non-frozen interfaces". It seems too tight. Only one of the long list of <a href="http://www.linux.org/docs/ldp/howto/Program-Library-HOWTO/shared-libraries.html#AEN135">ABI breaking techniques</a> pertains to the XPCOM: c++ #2 - add or remove virtual member functions. However, according to c #2 of the same article, the library can append any structures it allocates. A c++ vtbl is just like any structure, and in XPCOM terms allocating means implementing.

If the above is correct, the XPCOM can raise a new flag:"just don't IMPLEMENT non-frozen interfaces from c++". This will add three restrictions the XPCOM side after a release:

• all callback interfaces need to remain stable;
• non-callback interfaces may only be appended;
• or release a new version.

Enforcing democracy </dt>

Branded mozilla applications can DETERMINE whether an add-on is compatible, as opposed to ASK for add-on developer's opinion. This may be done as follows:

• each add-on should declare its minimal gecko version;
• platform keeps a database (in any form) which relates nsIID to the gecko version, when it was last changed/introduced. The database is merged into xpti.dat on each update.
• when nsComponentManagerImpl instantiates an object from an add-on module (compreg.dat will let know this), it will check whether the interface is in the database. If so, than whether its last change gecko version is greater than the add-on minimum gecko version. If this is also true, than the object is not created, and the add-on is blacklisted.

Proposed measures will surely slow down component registration and extensions, but will substantially elevate stability of updates.

Reducing complexity </dt>

It is a commonplace that mozilla is excessively complex, and its entry barrier is prohibitingly high. Only the most brave coders can experiment on a platform with 30 minutes build time. Mozilla and GNU boost each other. GNU won't be able to spread without a high quality browser, and mozilla depends on sophisticated GNU build system. GNU has a recipe to fight complexity. It uses many small components. A similar approach may work for mozilla:

• mozilla already has modular structure, which may be enhanced:
  • enforce strict rule: a call to NS_GetModule = a mozilla module;
  • distribute tools, non-xpcom code and resources among modules;
  • reveal inter-module dependencies;
  • remove mutual dependencies by splitting modules.
• give each module its own build system. It is easier said than done, but a module is considerably more simple than the whole project, and we are building the whole project. In addition, we have precedents like nspr, which is effectively a subproject.
• make dist/bin dependent on installation as a normal cygwin/'nix package, not vice versa.
• add --with-<module> ./configure options.

This will have a great deal of effects:

• add-on may be built as a cygwin/'nix packages, which depend on top-level application's cygwin/'nix package. And then be packaged for distribution. Immediate consequences:
  • no need for mozilla source tree downloading/configuring/building;
  • skills, required to create rich extensions, will be:
    • basic GNU programming;
    • basic (XP)COM programming.
• it will only take to rebuild changed modules, not the whole tree, if the ABI is preserved. Build & install time will be in seconds, not hours.
• even if the ABI is changed, only the dependent modules will require attention. At the top of the tree, it is practically the same as previous.
• we can install multiple version of modules. This is enabled by so versioning on 'nix and dll bundles on w32 (or i386 PE by GNU ld classification).
• we can drop startup scripts on 'nix. if we install major libraries in libdir as opposed to pkglibdir, we won't need to set LD_LIBRARY_PATH.