Archive for the 'mozilla' Category

I uploaded xulrunner 1.9~b5-1 yesterday, and today was webkit's turn, with an upload of svn revision 31841, which happens to be the last revision on trunk as of writing.

Thanks to Mark Rowe, the most problematic crashers I experienced with webkit while preparing this upload have been fixed in revisions 31821 and 31787. This had the side effect to delay the upload enough that we now have the benefit of improved SVG animations support, and CSS gradients.

For those who like numbers, you can take a look at the Sunspider results for xulrunner 1.9~b5 (running mybrowser ; very similar results to what I got with 1.9~b4), and Sunspider results for webkit r31842 (when you compare to previous results for webkit r27674, there are significant improvements).

For another kind of numbers:

~/git/xulrunner$ git diff upstream/1.9... | filterdiff -x b/debian/* -x a/configure | diffstat | tail -1
36 files changed, 507 insertions(+), 291 deletions(-)

Compared to:
~/git/xulrunner$ git diff upstream/1.9...1.9+b4-1 | filterdiff -x b/debian/"*" -x a/configure | diffstat | tail -1
53 files changed, 932 insertions(+), 466 deletions(-)

~/git/webkit$ git diff upstream... | filterdiff -x b/debian/* | diffstat | tail -1
1 file changed, 4 deletions(-)

Compared to:
~/git/webkit$ git diff upstream...0+svn27674-4 | filterdiff -x b/debian/* | diffstat | tail -1
17 files changed, 61 insertions(+), 18 deletions(-)

Somehow, I prefer to work on webkit...

It finally happened, sorry for the delay. 1.9b4 is currently being uploaded to experimental. Yes, I know, this is not 1.9b5, which was released a few days ago. This is because I wanted to do some more work on 1.9b5 and didn't want to delay the upload any longer.

Now, for the uninteresting statistics, following are the diffstats, excluding directory debian/ and configure:

for version 1.8.1.13-1: 113 files changed, 1393 insertions(+), 824 deletions(-)
for version 1.9~b4-1: 53 files changed, 932 insertions(+), 466 deletions(-)
for work in progress version 1.9~b5-1: 39 files changed, 848 insertions(+), 423 deletions(-)

(the latter will obviously evolve)

I appear to have underestimated the remaining work needed to get xulrunner in a pleasant enough shape for an upload. Which means the package won't be ready this week-end. It's always when you come closer to the goal that it gets farther...

And I still haven't decided once and for all if I would still version the libxul library. The problem is the following: there are two different ways to link or load libxul: dependent glue or standalone glue. The first one dynamically links embedding applications to both libxpcom and libxul, while the second links to a static library (well, dynamic, in Debian, because there is no reason why we should need to binNMU all reverse dependencies whenever we fix something in the glue), which dlload()s libxul. From Mozilla POV, embedding applications are supposed to use the standalone glue.

Considering we will more than probably have both schemes in use within reverse dependencies, I'm not sure I still want to bother diverging from upstream by keeping SO versioning on libxpcom and libxul... That unfortunately means that we will go back to the previously sucky situation where reverse dependencies have to put a dependency on the Gecko runtime themselves. A debhelper might help, though.

I will keep SO versioning on libmozjs, though, because it has some reverse dependencies, and a changing ABI.

The good news, anyways, is that I was able to build and run Iceweasel on top of the xulrunner pre-package.

I also ran sunspider on both this Iceweasel 3.0b4 and Iceweasel 2.0 ; the difference is really impressive: 3.0b4 is almost 4 times as fast !

For reference, the Webkit currently in unstable (which is quite old, actually), gives these results. The one in experimental unfortunately crashes. By the way, I'm planning to package a new Webkit snapshot soon after I'm done with xulrunner and Iceweasel, we'll see then how it performs.

While speaking of tests, both Iceweasel 3.0b4 and Webkit from experimental pass the Acid 2 test (contrary to Iceweasel 2.0), and have both quite good results on the Acid 3 test: 61 for Webkit from experimental, when it doesn't crash (but current trunk has been reported to score 91 !), and 67 for Iceweasel 3.0b4 (compared to 52 for Iceweasel 2.0).

Update: Interestingly, built with upstream optimization flags (-Os-freorder-blocks -fno-reorder-functions) instead of -O2, it is slighly slower, though it might be better on some older hardware, or other architectures (I'm testing on x86-64).

It's been a while I've not talked about my packages. I've been preparing a xulrunner trunk upload for a while now, and I must say that while I'm not totally happy with evolutions in Mozilla codebase, I do appreciate that a significant amount of the patches we were applying have been applied upstream. And even more will be applied when Firefox 3.0beta5 is released. I even got patches that were *not* in Debian to be applied. Thanks have to go to Reed Loden for all this.

Another nice thing on Mozilla trunk is that they finally stopped patching sqlite, which means we can now have Mozilla linked against the system one. It is even more important now that libnss uses sqlite, too.

And now that we have libcairo 1.5 in experimental, and recent enough nss and nspr in unstable (uploaded a few days ago, creating some mess with iceweasel, iceape and xulrunner), we have all the necessary bits to have (most of) the bundled libraries replaced by system ones.

The sad thing is they did implement APNG (animated png) in their bundled libpng, so, to have APNG support, we need to either patch libpng or use the bundled one. I'll see if I can just disable APNG for the moment.

I hope to be able to upload the package to experimental on saturday or sunday, based on the firefox 3.0pre4 codebase. Iceweasel should follow a few days later.

As MJ Ray reports, ftp.mozilla.org now has "Free software" Firefox tarballs. While they are truly free and don't contain the non-free logo nor Talkback, they are not Firefox either. Only the tarballs and the executables are named Firefox. The product itself is "Bon Echo". And the name is going to change at every major release. This is why we changed for a "static" name.

Ars Technica has recently posted an article about the new Opera alpha release, with some Javascript benchmark results showing it is quite faster than version 9.23. It also goes to compare with Firefox and IE7, but omits some other not so unimportant browsers. I think the main reason is because they seem to have only tested Windows browsers. Sure, Safari has been released recently on Windows, but it is still quite marginal.

Anyways, I was wondering how all this was going under Linux, and also, how (good?) WebKit would perform compared to others.

So, I tried the same Javascript speed tests on various browsers under Linux on my laptop, which happens to be a Pentium M 1.5GHz.

And the winner is...

So, It seems the speed gain Opera got on Windows doesn't happen much on Linux.

An interesting result, is that Iceweasel, with a bunch of extensions installed, is slower than Epiphany, despite both using the same rendering engine and Javascript library. Running Iceweasel in safe mode makes it the same speed as Epiphany, though. So having extensions does not only clutter the UI, but actually has an impact on how fast the Javascript code in web pages is going to run.

And well, WebKit is the fastest for this testcase, though it stays behind Opera on some specific tests.

So, after having dumped Mozilla Suite, the Mozilla Foundation is now pushing Thunderbird out to pursue its goal of an "open web" (understand: MoFo only cares about Firefox).

Why is it called the Mozilla Foundation, again ?

... is that more than one are likely to have the same crazy ideas.

When I started to play with xulrunner, which according to my oldest post in the xulrunner category would be near 2 years ago, I had this crazy idea (and here, when I say crazy, I almost think dumb) that it would be neat to have a window manager based on libxul, being able to display both "native" windows and XUL or HTML windows.

Indeed, it would be neat, as in web-2.0-hype or i-can-use-gmail-directly. But that would be so much impossible to secure, and introduce so many different new ways to compromise users...

Guess what... It now exists.

Update: Waw, the GUADEC keynote slides are really full of crap. My favorite ones are about "The Fox" : Good engineering practices and Small, extensible core.

After Camino and Seamonkey, Epiphany is joining the let's have a dumb UA club.

Instead of actually fixing the problem at its root by forcing stupid people not to try to match Firefox, by totally removing Firefox in Firefox's UA, which would definitely have had a good result, they go the opposite direction.

If I see that crap coming in Debian in either epiphany, galeon or kazehakase, or any other browser based on libxul, I promise I'll hack the thing that puts the user-agent together so that it suppresses all occurrences of Firefox from it.

If only people at mozilla were as thoughtful as Robert Kaiser...

I've been using svk for xulrunner maintenance since the first test packages. And I've been thinking about switching to git for a while now. I did some testing in march, which led to my post about diffing. I went a bit further today by actually trying to convert my svk repository. And I got both interesting and surprising results.

The repository is (only) about 250 revisions in svk, and includes 15 upstream releases (or CVS pulls). I had to reorganize the svk repository so that git-svnimport could do its work properly.

[ Note: these tests have been done on a 5 years old laptop ]

The first surprise is the time it took for the conversion : almost half an hour. Dumping (svnadmin dump) and reloading (svnadmin load) the svk repository takes a bit more than 3 minutes, in comparison... I guess git-svnimport is very ineffective.

The second surprise is that the svk repository is actually almost twice as small as the git equivalent: 116MB for svk vs. 224MB for git.

On the other hand, git is amazingly fast. One of the most common things I do on this repository is a diff between the upstream branch and the trunk. I create the .diff.gz file I give pbuilder this way. It's much quicker than doing a real dpkg-source, especially considering pbuilder does one itself.

After dropping caches (echo 3 > /proc/vm/sys/drop_caches), such a diff takes about 50 seconds with svk and... a little more 2 seconds with git. Without dropping caches, it gets down to 38 seconds with svk and... 0.05s with git. That is pretty damn fast !

Update: after a git repack -d, the git repository is down to 61MB.