Changes

Jump to: navigation, search

Potential Projects

620 bytes removed, 17:51, 31 July 2008
Mozilla Potential Mozilla Projects clean-up and additons
Resources: Cathy
 
== Add OpenID support to Bugzilla ==
 
Many open source projects rely on bugzilla for bug tracking, and open source developers use different instances, forcing them to have multiple logins. Complete OpenID support in bugzilla.
 
References: reed, [https://bugzilla.mozilla.org/show_bug.cgi?id=294608 bug 294608]
 
== Tbeachball - Quantifying Mozilla's Responsiveness ==
 
This project will add instrumentation to Mozilla in order to determine how much time is spent away from the main event loop, and therefore from the user's mouse/keyboard input. When the user does something, how long does it take for Mozilla to act on that stimulus? One thing that sometimes interferes with interface responsiveness is spending too long away from the main event loop, perhaps in layout or some other intensive computation. This leads to new events from the user, such as mouse clicks or keypresses, not being noticed and acted upon. This could also be expanded in order to include the triggering of log points and specific dialog openings, etc. with a view to understanding what the long-running events actually are.
 
References: http://shaver.off.net/diary/2007/08/25/tbeachball/ and http://shaver.off.net/misc/latency-tracing-patch.txt
 
== Convert password storage to a SQLite database ==
 
Currently, Firefox stores logins in a text file in the user's profile (signons2.txt). The format is simple, but inflexible. Storage of other browser data, such as cookies and form history, has steadily been moving towards using SQLite-backed databases so moving password storage to the same kind of storage would be good. Some work was started in [https://bugzilla.mozilla.org/show_bug.cgi?id=288040 bug 288040].
 
References: dolske
 
== Refactor master password out of NSS ==
 
Users can enable a "master password" in their browser, which securely encrypts all their stored passwords. The current implementation can be awkward to use and has some limitations, see [https://bugzilla.mozilla.org/show_bug.cgi?id=322617 bug 322617]. Fixing this would involve having password manager being more involved with the cryptography operations -- deriving a key from a passphrase with PKCS#5, and using NSS and PKCS#11 to encrypt/decrypt entries.
== Add Offline Support to an open source web app ==
Lots of web developers use Firebug and Firefox for building their applications, but we want those apps to work well in other browsers as well. If Firebug knew about JS or CSS patterns that could cause problems in other browsers, it would make it much easier to have those applications work in all browsers.
Resources: mfinkle, robcee
== Add-on update helper tools for developers ==
Resources: mkaply, bsmedberg
 
== Add MSI packaging to the Firefox build system ==
 
Firefox is not currently available on Windows as an [http://en.wikipedia.org/wiki/Windows_Installer MSI], which is something IT departments and others deploying on many desktops routinely request. The [http://en.wikipedia.org/wiki/WiX Windows Installer XML toolset (WiX)] is an open source tool provided by Microsoft that allows the creation of MSI files based on XML config files. This project will add MSI packaging to the Firefox build system so that it happens by default.
 
Resources: mkaply, ted, http://www.frontmotion.com/Firefox/index.htm, http://forums.mozillazine.org/viewtopic.php?t=138033
== gdb symbol server support ==
Many (poorly behaved) web sites attempt to move and/or resize your browser window. It is possible to stop this behaviour (cf. dom.disable_window_move_resize) but it would be nice to have an infobar that informed the user that a web page attempted to move/resize the window, and allow it or ignore it (default). This behaviour is similar to the current Pop-up Blocker already present in Firefox. NOTE: it is not clear whether such a feature would be accepted in the tree or if this would need to be done as an extension.
 
== Add DTrace probes and scripts for Mozilla code base ==
 
[http://en.wikipedia.org/wiki/DTrace DTrace] was created by Sun in OpenSolaris to allow developers to write simple scripts in order to probe and instrument executing programs in a way not possible otherwise. One of the advantages of DTrace is that it allows you to turn on probing when you need it, but not incur an execution penalty with regard to performance (i.e., when probes aren't being scripted, they aren't run). This requires developers to add "probes" to their source code. For example, if you wanted to know when a particular function is entered/exited, get info about what happened, etc. you could add probes to the particular function. Writing the probes is not difficult, however there are hundreds or thousands of probes that Mozilla would like across its code base.
 
Resources: sayrer
 
== Colour Management Tests ==
 
Write [http://developer.mozilla.org/en/docs/Creating_reftest-based_unit_tests reftests] to compare images in order to deal with floating point tolerance. This includes dealing with things like Monitor Profiles, profiles in JPEG (i.e., JPEGs get changed based on colour profile info). See discussion of colour profiles in Firefox 3 [http://www.dria.org/wordpress/archives/2008/04/29/633/ here]. It would be useful to be able to compare to PNGs with a reftest, perhaps creating an image diff tool, where pixels outside a floating point tolerance (> 0.n) would somehow be highlighted so you can see what is different. Little CMS (lcms) needs test coverage too.
 
This will require some graphics and image knowledge (i.e., Photoshop, what colour is on a computer, etc).
 
Resources: #gfx, joe, vlad
 
== Plugin Code Test Suite ==
 
Create a [http://developer.mozilla.org/en/docs/Plugins plugin] test suite. There are currently no tests of any kind, and this code is very brittle and not well understood. This would involve creating a plugin or set of plugins and some html/js to drive that plugin in order to push test coverage. Maybe look at the JRE tests, create some specific plugin cases (e.g., swf to load that tests flash specific code).
 
This will require C programming, as well as light web development (html, js, perhaps swf).
 
Resources: jst
= Potential OOo Projects =
Retrieved from "https://wiki.cdot.senecapolytechnic.ca/wiki/Special:MobileDiff/15792"

Navigation menu