I will be on vacation from this Friday (16-September) through the next week on the outer banks of North Carolina; I’ll return on Monday, 26-September. I do not intend to check e-mail at all during my vacation… If you need reviews for patches targeted at the 1.8 branch, please request them ASAP.
Archive for 2005
This week Mozilla bought be a brand-spankin-new uber-powerful computer. I’m still getting to love it’s wonderfulness. I rearranged my machines so that the new machine (dual Athlon64, 4gig RAM) is running WinXP, my former Windows machine (Athlon64, 1gig RAM) is running FC4 (x64_64), and I’m going to retire my rather ancient Athlon1.2gig box which is running RH9.
The new Fedora Core has been giving me fits. First of all I couldn’t get the DVD image burned until the fifth try, for unknown reasons. Then the anaconda installer didn’t like some combination of custom install options I gave it. I finally broke down and told it to do a default “Workstation” install, and it finally installed.
Next, I tried to get both of my video cards to work in this machine. No dice. If I set the AGP card as the primary card in CMOS, I can’t get the secondary (PCI) card to display anything at all. If I set the PCI card as primary, I can get it to show up the first restart, but after that it doesn’t work again. Funnily, occasionally the boot sequence tells me that it found new hardware, please enter my root password. But I can never seem to enter it correctly…
Now, I’m running into the GCC 4.0 bug where hidden-visibility symbols are not compiled correctly, leading to the following error:
/usr/bin/ld: jsapi.o: relocation R_X86_64_PC32 against `memset@@GLIBC_2.2.5′ can not be used when making a shared object; recompile with -fPIC
Shaver said that this bug was fixed on the gcc4.0.x cvs, so I tried to build GCC from CVS. I can’t. I try the following configure steps:
CFLAGS="-m64" ../4.0.1-branch/configure --prefix=/builds/gcc/4.0.1-branch-installed --enable-languages=c,c++ --host=x86_64-redhat-linux --enable-shared --enable-__cxa_atexit --with-system-zlib
Compilation fails after a while with the following error:
./xgcc -B./ -B/builds/gcc/4.0.1-branch-installed/x86_64-redhat-linux/bin/ -isystem /builds/gcc/4.0.1-branch-installed/x86_64-redhat-linux/include -isystem /builds/gcc/4.0.1-branch-installed/x86_64-redhat-linux/sys-include -L/builds/gcc/4.0.1-branch-objdir/gcc/../ld -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I32 -I../../4.0.1-branch/gcc -I../../4.0.1-branch/gcc/32 -I../../4.0.1-branch/gcc/../include -I../../4.0.1-branch/gcc/../libcpp/include -m32 -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-unit-at-a-time -fno-omit-frame-pointer -fno-asynchronous-unwind-tables \ -c ../../4.0.1-branch/gcc/crtstuff.c -DCRT_BEGIN \ -o 32/crtbegin.o In file included from /usr/include/features.h:337, from /usr/include/stdio.h:28, from ../../4.0.1-branch/gcc/tsystem.h:90, from ../../4.0.1-branch/gcc/crtstuff.c:64: /usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or directory
Does anyone know why, when I configured explicitly with -m64, it is still compiling with -m32 and looking for the 32-bit headers (which do not exist on this system)?
A helpful soul (pinskia) on irc.oftc.net/#gcc told me to use –disable-multilib and I seem to be in business. I would still like to figure out what I would need to install to get multilib working. Obviously redhat has multilib.
Friday, I received in the mail a check for $5,000 from a bank I had never heard of before. My wife went through the mail, and when she read the fine print on this check, she discovered that it was actually a five-year loan, at 27.199% interest. In case you don’t have a financial calculator, the total cost of the loan would be $9,176.
Leaving aside the deceptive practice of disguising a contract in the form of an unsolicited check, this loan offer is a truly despicable form of usury. For some reason I don’t understand, it is no longer fashionable to call anything usury. But usury is not only immoral, it is still a crime in most states. Unfortunately, the U.S. congress gutted state laws against usury in 1980 by exempting federal banks from state usury laws. The did this under the guise of protecting banks against inflation, but it was actually a neoconservative triumph of laissez-faire economics over decency and justice.
It is amazing that Beneficial has posted a document on responsible lending practices which seems to be so much at odds with their actual practices. Just because this bank is probably not doing anything illegal does not mean that we should tolerate deceptive and usurious practices that prey on the poor, mentally retarded, and elderly. I encourage you to write to the bank and tell them what you think:HSBC – North America
2700 Sanders Road
Prospect Heights, IL 60070
I also encourage you to write to your congressman and ask them to add them to toughen U.S. usury law so that state laws apply, or at least a reasonable interest limit is applied.
In June I was at the Mozilla Foundation for a week for an all-hands meeting. During that week I met a bunch of great folks I had only ever met on IRC, including dria, mconnor, pav, shaver, and vlad (in alphabetical order…). When we weren’t in official meeting of various sorts, there was time to get together in small ad-hoc working groups; these working groups were very productive and informative for me.
During one of WG sessions, vlad and mconnor and I came to a consensus: the current method of constructing XUL (Firefox/Tbird/whatever) themes is fragile and should be rethought. We came to the conclusion that most of the core styling instructions should ship in content packages, not skin packages. Skin packages would only contain theme-specific CSS overrides which alter the default theming instructions. The default theme will therefore contain empty skin CSS files.
This will make it much easier to skin applications in gecko 1.9; instead of duplicating every style rule in the classic theme, which is basically what theme authors do now, authors can simply override the elements that make their theme unique. This may simply be changes to a few icons, or colors, or whatever, but it means that themes are much more likely to be stable and work with multiple future versions of the application.
This work is being tracked in bug 305746.
People frequently send me e-mail to ask me questions or discuss XULRunner. While this is not an entirely bad thing (I like hearing what people want from XULRunner and the Mozilla “platform”), it gates a lot of discussion through me, which can slow things down considerably. I would like to recommend the following communication channels for people who have general things to ask about XULRunner:
- For general development questions pertaining to XULRunner applications, let’s use the netscape.public.dev.xul newsgroup;
- For questions about using XULRunner in embedding contexts, use netscape.public.mozilla.embedding;
- For discussion and planning about the development of XULRunner itself, I have created a semi-private mailing list XULRunneremail@example.com. This list is meant for serious developers who are working on XULRunner’s design and implementation. The archives are public, but list membership is by invitation only. If you would like to be part of this list, please email me privately and let me know.
I would also like to encourage XUL application developers to write articles for the XULRunner section of the Mozilla Developer Center. Writing XULRunner apps is pretty simple, but only if you have a good guide to get you started!
I have been trying to follow Joel Spolsky’s advice. Right now it is very hard to say “XULRunner 1.9 needs X hours of work to be ready for production use” because basically nobody (including myself) has any clue what concrete tasks are needed to get from here to there. I have a pretty good mental overview of the tasks, but that is a far cry from “it would take me 412 programming hours to complete them”, and even less the amount of debugging time to get to a final product.
Bugzilla is a pretty good bug tracking tool, but it’s painfully unsuited at task management and software scheduling. Joel recommends a simple spreadsheet, but that has some serious problems when I need to expose the data for lots of people on the web, and probably need to allow multiple programmers to fill in data. Instead of doing nothing, waiting for bugzilla to get better, I have written a little tool to help me manage XULRunner. It uses a custom XML dialect and some XBL magic to create a hierarchical list of tasks, with estimated and actual times for completion, and automatic totals.
Actually, I’m lying. I wrote two different versions of this tool, each with its own problems. I’m posting both URLs for comments and suggestions:
- XUL version that uses server-side persistence – view. This version loads a XUL page directly into memory: the page can be edited inline and saved back to the server using the menu. If this were the final version, I would probably include auto-save functionality and maybe some other stuff. The big advantage of this version is that it persists the open/closed state of each item. The big problem with this version is when two people try to edit simultaneously: there is no collision detection, and there is no real possibility of smart-merge. Currently the “save” functionality is password-protected. If enough people are interested, I’ll make a “playground” version.
- Wiki-based version – view | edit. This version cannot be edited inline: you have to edit the wikimarkup manually… but the markup is pretty readable all on its own, so you don’t even have to use the “view” version if you don’t want to. The big disadvantes of this version are the lack of inline editing, and no persistence of the open-closed state. This version makes use of a special mediawiki patch that allows wiki pages to be viewed “raw” in various mime types, see bug 300657.
Right now, I’m going to use the wiki-based version. In the future I may try again with some special database-oriented system in the future, but this version is “good enough” for my needs; I need to actually work on the data for XULRunner 1.9!
What would be really nice is to make bugzilla less painful to use, and integrate this kind of project-management data into it, but that is a topic for another day.
Over the past few months, I have had a number of companies and individuals come to me and ask about enhanced or stripped-down versions of XULRunner. Replying to these questions has helped me hone my thoughts, and eventually reinforced my early decision that XULRunner (libxul) should ship a well-thought out set of component/features and should not be configurable. Optional features, whether “extra” or “stripped down”, come with significant and unjustifiable cost in terms of code maintenance, documentation, and QA.
The Mozilla suite has traditionally supported all sort of configuration flags that allowed browser customizers to disable or add optional components. There were build-time flags to disable/enable features such as XMLHttpRequest, webservices support, multi-profile support, or even cryptography (at one point this was required by law).
The various components were joined through XPCOM interfaces and XUL overlays. In theory, each component could be cleanly disabled without affecting other components. To some, this separation of components was (and is) one of the major benefits of the Mozilla codebase: embedders and redistributors are able to select the particular features they wish, without the burden of distributing unnecessary extras.
The Mozilla Platform
Any web browser is a miniature operating system, a “platform” on which web applications can be built. The Mozilla codebase is doubly a platform because of its ability to build rich-client applications and extensions using technologies such as XUL. One of the most important aspects of any platform is that it is all about developers.
Web developers do not want to have to figure out whether their customer is using a special gecko with XMLHttpRequest or XSLT disabled: they want to be able to test their app against a few versions of Firefox and against IE and say “it works”, and then move on to more important things like saving the world or making money.
XUL+XPCOM developers are in an even worse pickle: XPCOM interface documentation has traditionally been sparse to non-existent, and it is frequently impossible to tell what interfaces and XPCOM components would be available and functioning properly with various features configured off.
The Cost of Options
What seems at first glance a benefit to embedders and distributors turns out to have significant consequences; these consequences come in four forms:
- web developers;
- user and web developer documentation;
- quality assurance;
- the Mozilla codebase itself.
The cost to web authors is immediate and painful. Not only are they requied to deal with multiple version of gecko, each with its own bugs, but also with feature differences within gecko versions depending on the distributor or embedding context: will XMLHttpRequest be available to my web page? What about XSLT? box-model layout? Web authors need there to be “one gecko” with standard features that “just work”.
The cost to the mozilla codebase itself is twofold. First, the build system has developed undue complexity to dealing with combations of optional components. But more importantly, significant platform features have been unimplemented because of the “bad” dependencies they would introduce. The most obvious one that comes to mind is extending the XUL overlay syntax so that overlay elements can be inserted at arbitrary locations specified in xpath. Since xpath is part of an optional component, this change has been on hold for a long time due to resistance that XUL might depend on the optional XPath component.
The Testing Matrix
The hidden and probably most expensive costs incurred by optional featuritis are found in documentation and quality assurance. Every time you add an optional feature you add an exponential permutation to the feature testing matrix. It is certainly non-obvious that enabling the “typeaheadfind” extension in Firefox breaks the browser, but it is so! Is is also a non-obvious implementation detail that disable XSLT disables pretty-printing, and disabling “xmlextras” means that none of webservices works. Every permutation must also be documented in the web developer and XPCOM documentation. The sheer complexity of the task guarantees that neither the documentation nor the quality assurance tests can be both comprehensive and accurate.
A good Testing Matrix (which we have yet to achieve) requires intensive sets of testcases integrated with the Mozilla QA process and TestRunner. At the least, every frozen interface, and every web-developer API should have an automated testcase; visual features should also have a human-read testcase. I am excited about the TestRunner project and look forward to the future when this can be a regularly tested reality.
The alternative to the extreme modularity of our codebase and ad-hoc featuritis is to have a definitive list of features that are part of our platform (both our web platform and our XUL+XPCOM platform). Our shipped features must integrate with each other and must not have dependencies which cannot be tested.
The list of features that I have specified for XULRunner can be found here. For the most part, this list was compiled as follows: every feature that will be part of our public “DOM” APIs is included. In addition, the core XUL language, and the features which are required to bootstrap a typical XUL application are included. Finally, it includes various features which seem to be desired by many XUL application authors (spellcheck APIs) or which would be very difficult to add as application-specific code (JS debugging).
But What About…
There are two camps of people who dislike my plan: developers who want more features in the XULRunner, and developers who want fewer.
If your favorite feature is not on the list, please don’t rant! You can probably include this feature in your application directly… it just won’t be shared with other applications. In most cases, extra features are be avoided for one of two reasons: 1) it’s not feasible to include it in the testing matrix or 2) not enough people would use it to justify bloating the XULRunner (and therefore Firefox) download weight.
Projects like Minimo and Chandler  , as well as several commercial groups, have expressed interest in a stripped-down XULRunner. Chandler would like basically a replacement for wxWidgets, without all the networking/SSL/etc code that comes with XULRunner. Minimo wants the networking/SSL code, but would like to strip out unnecessary XUL features and perhaps some of the more memory-hogging web features such as XSLT and (depending on the target device) xmlextras, webservices, etc.
I don’t think that either of these approaches will be successful in the long run. The strength of the Mozilla platform must remain in its innovation, stability, and documentation, and I do not believe it is possible to maintain a “split codebase” where some features are second-class or may not be present. To get a sense of what I mean, in terms of Minimo, see bug 302577.
Coda: Download Weight
Download weight is obviously important to a certain class of mass-market applications, though certainly not to all. The design requirements for XULRunner specify is that it maintain a small enough footprint for use as the runtime for Firefox, which therefore requires something smaller than 4.5MB (Windows) when optimally compressed (using 7zip). That is currently the case (the windows ZIP builds are 5.5MB, but that’s with significantly non-optimal compression), and we intend to stay well within that range and perhaps even improve the current Firefox target with various linking and code generation optimizations. The goal is not to be Java or .NET, with a fantastically heavy base runtime, but instead to be a runtime that allows for a range of networked applications, from existing web applications to semi-privileged offline web applications to fully-privileged client applications, using traditional web technologies and languages.
In case you have not heard, one of the very important new Mozilla initiatives is the documentation project called the “Mozilla Developer Center”, or “devmo” for short. Mozilla has already proved successful at open software development and open community-based marketing, and this is the next logical step: an open, community-based documentation resource for web developers, extension authors, XUL application developers, and core Mozilla developers.
This documentation effort is in full swing right now; visit http://developer-test.mozilla.org/ to see it in action. It is powered by MediaWiki, a powerful and extensible piece of server software that allows for community collaboration in editing documents. Mediawiki has a long track record as the software that powers Wikipedia, the free encyclopedia.
I am personally very excited by the energy I already see in the devmo project, and it’s explosive potential when it is actually “launched”. One of the historical weaknesses in Mozilla as a development platform is the lack of good documentation, and devmo is taking up the challenge in a big way. Devmo is under the experienced leadership of Deb Richards, who I have gotten to know over the past few months as person who can keep an vast number of things going and not lose sight of the final goal.
Which is why I am writing this post not to rain on the parade, but to discuss the challenges that I see facing the project. Most importantly, how devmo presents dense reference material is going to be critically important to its most important “consumer”, web developers and XUL application authors. The wikitext format lends itself quite readily to tutorials and articles, and I am working at making code samples work without a lot of pain. But reference material is not easy to either write or present in traditional wiki format. For a point of reference, please visit the msdn.microsoft.com page about the html <applet> tag. To understand what I really want out of devmo, visit that page in IE.
The property list is presented as a dense and highly-hyperlinked table. But the most important part of that table is that it is absolutely complete. You don’t have to go visit “the properties of DOM Objects” and “the properties of HTML Objects” to see what is available on this DOM element. But I want more! I want to be able to say “show me which properties were available in mozilla 1.x”.
When the gecko developers add a new method to a DOM object, it is unlikely that anyone is going to systematically go through and add this property to every one of several hundred individual element pages with the correct descriptive text and versioning information. Reference material is a recipe for out-of-date or incomplete documentation; documentation which does not list the minimum runtime for which a particlar method/property/style became available is almost worse than useless.
I believe that creating this kind of dense documentation is going to require that these cross-references are created in some kind of XML syntax. I believe that this XML should live in a wiki “page” so that it can be edited by the community like any other page. The advanced sorting capabilities that you see on the IE version can be provided through the use of XBL bindings in such a way that clients which do not support XBL will get the full property table (there are other possible solutions involving cross-browser scripting which would be more complicated but would be compatible with more browsers).
Finally, one of the major features that I want out of devmo is to provide context-sensitive help in rich-client editing tools. Everything from the XUL Application Creator slated to be part of the XULRunner Developer Kit to NVU could really use context-sensitive help when editing markup of various kinds including HTML/XHTML/XUL/CSS/JS. For this to be practical, large parts of the metadata provided by devmo will need to be in machine-readable formats.
I know that I am asking a lot out of devmo. It’s not going to get there overnight, and that should not stop anyone from contributing an article or helping edit right now. I especially encourage people with editing skills to get involved and clean up the articles that people like me might write.
I was stuck in a funk yesterday, trying to get XULRunner application bundles working properly on Mac OS X. The basic problem is that I’m trying to run the xulrunner-bin executable from the XUL.framework, but have the launch manager think that it is running as the application bundle (using the application bundle dock icon/application name/etc). The basic strategy is to have a little stub binary inside the application bundle which will execv to the xulrunner-bin binary. However, this wasn’t working… Launch Services was convinced that the xulrunner-bin was running on its own, and because it is part of a framework instead of an application bundle, it was running as a background application (no access to the dock or menus).
In my frustration I visited my infrequent hangout freenode #opendarwin, who were quick to inform me that launch services was not their domain, but that I should visit #macdev.
<bsmedberg> Is this a decent place to ask questions about application bundles and launch services?
<mikeash> I wouldn’t call it decent, “wretched hive of scum and villainy” is more appropriate
<bsmedberg> Is there some way to run /foo/bar-executable but tell launch services to pretend that it’s running as part of /bar/MyApp.app ?
<mikeash> “as part of”?
<bsmedberg> Basically, I want to stick a “runtime executable” in /Library/XUL.framework/Versions/<foo>/xulrunner-bin
<bsmedberg> sorry, /Library/Frameworks/…
<arwyn> so you want to have your normal app bundle in /bar/MyApp, but you want the actual executable file to be from /Library/XUL.framework,e tc?
<bsmedberg> And when a user runs /bar/XULApplication.app it will have a little stub binary at Contents/MacOS/xulrunner-stub
* arwyn suggests a symlink
<mikeash> that sure sounds like odd design
<mikeash> I *think* that if your app’s main executable just execs the other one, it’ll work, but I’ve never tried it and I’m nowhere near sure
<bsmedberg> it doesn’t work to execv the other one :-(
<arwyn> what doesn’t work?
<bsmedberg> the xulrunner-bin doesn’t get menus/dock icon (can’t activate the window)
<arwyn> and to be clear, we are talking about exec() the system call… not relaunching via LS
<mikeash> does xulrunner-bin work properly when it’s actually the main executable of your app?
<arwyn> in your exec(), did you preserve the original argv parameters so that the OS will think the bundle is still located in the right place?
<bsmedberg> as long as all the rest of the XUL framework is along with it
<bsmedberg> arwyn: no, I didn’t… does the OS use the argv to determine the bundle?
* bsmedberg gets excited
<arwyn> yes, there is no other way
<bsmedberg> cool, I’ll try that, thanks
<mikeash> arwyn, aren’t there undocumented ways, like env(“_”) or something?
<arwyn> I know this type of re-exec() trick can work, people on this channel have done it
<arwyn> it might just need some tweaking
<mikeash> I think that Firefox does it
<bsmedberg> well, no
<bsmedberg> Firefox execs itself, but it’s the same binary
* bsmedberg wrote that code
<mikeash> I don’t think that being the same binary is going to magically make it work, and being a different binary is going to magically make it break
<arwyn> mike, maybe… I’m not entirely sure
<arwyn> binary doesn’t matter at all, its all paths & args
<mikeash> arwyn, anyway, irrelevant since Apple does apparently use argv
<arwyn> argv is accessible via the NSGetArgv() stuff in Libc, which is what CF/NS uses to get it later to do main bundling
<mikeash> I can’t even think of a way that LS could even detect that you’ve re-exec’d, much less figure out whether you re-exec’d the same binary or a different one
[snip a long discussion that I didn’t understand about how the Mac OS could do this differently if it really wanted to]
Thank you Mike Ash and arwyn (whose real name I don’t know) for your invaluable help! I would probably be rearchitechting how mac bundles launched the XULRunner if it weren’t for you.
There has been much confusion over what the XULRunner short-term plan is, and when various features are supposed to be available. This post is my attempt to define my short-term goals and plans and outline my timeline for important changes in the next milestone:
Update: The XULRunner roadmap is now being maintained at http://wiki.mozilla.org/XULRunner:Roadmap.
For the current milestone (gecko 1.8/Firefox 1.1), my immediate goal is to get a developer preview release of XULRunner that can be used to demonstrate capabilities and determine future feature needs. This release will probably not be especially useful for actual production deployment because it will lack some of the (very important) installer capabilities. The included libxul has many problems, such as exported nonfrozen symbols and a very nonfrozen API.
This developer preview release will be shipped as a framework DMG on mac, and a zip/tarball build on win/unix. There are experimental RPMs available for SuSE (and there hopefully will be some fedora-compatible RPMs as well). The XULRunner binary has the ability to register itself as a GRE for embedding purposes.
Assuming all goes smoothly, XULRunner will have the ability to install a xulapp from a directory or a zipfile from the commandline, as well as ship with a GUI xulapp to perform the same function. For the 1.8 timeframe this will not add the program to the Windows Add/Remove program list or set up a dependency tree very well (automated uninstall may not be supported, you would have to just delete the installation directory).
The major tasks left for XULRunner 1.8 are linking changes to the standalone XPCOM glue so that it does not depend on NSPR, the stub binary which is used by installed xul applications and the abovementioned xulapp installer code. Finally, the Great and Mightily Overworked Chase has promised that there are new tinderboxen on the way which will build XULRunner with SVG+canvas support and will actually start producing mac nightly builds at all.
In the 1.9 timeframe my goal is to make XULRunner a completely workable production solution for XUL applications including Firefox and hopefully Thunderbird, as well as for embedding applications such as Camino and Epiphany. There are many steps to this process, but my general approach is incremental:
- Make many useful XPCOM utility classes available from the XPCOM glue.
- Allow the build system to build Firefox as a xulapp. This will not be the default (yet), while work is being completed on the installation mechanisms.
- Get the windows installer working
- Build Firefox as a XULApp by default.
- Get the various platform-specific embedding mechanisms integrated tightly and freeze the basic necessities. Windows Mac GTK QT.