Archive for the 'xulrunner' Category

We have had quite a bunch of bug reports for some display corruptions in Iceweasel, most, if not all, of which are due to offscreen pixmaps being badly rendered by the X.org video driver.

If you happen to be a silent (or even vocal) victim, please give a try to these test packages: for i386 and for amd64. If that solves the corruptions for you, please leave a comment here.

Thanks

There seem to be some heat about the new Firefox feature that only allows you to open https urls with untrusted certificate after 5 clicks.

The situation is actually worse than what is depicted. Why? Because not only did they put crap to their users, and actually, if they want to, that's their problem, but they also imposed their crap on embedders.

Yes, this means applications such as epiphany, kazehakase, galeon, and others *must* use this crap. I know, there is a browser.xul.error_pages.enabled to disable the error page (note it also disables standard network connection error messages). But, the alternative is not any better: It opens a dialog, with raw HTML in it, allowing to... do nothing. That's it, you can only acknowledge you've been denied access to the so-called untrusted site.

The best part is that these applications can't (or maybe they can, but in several months nobody found how) make the exception dialog work properly: the user will have to enter, himself, the url to add the exception for. And before even reaching the state where you can get the dialog to open from the error page, or even get the buttons to be displayed in the error page itself, you have to add clutter to your application code.

For those still wondering what happened to the Gecko platform or whatever you call it (xulrunner, libxul, mozilla-embed, etc.), here is your answer: Gecko evolves with what Firefox needs. If your application needs something else, well, too bad for you. Firefox developers obviously have a big problem taking embedders into consideration when they change the Gecko API, and while it can be fixed afterwards, it's not a good thing to "tag" a Gecko milestone at the same time as a Firefox release under such conditions.

Anyways, what I did in the xulrunner-1.9 package is to forward-port the old interfaces (nsIBadCertListener) allowing embedders to have their own UI for this. While it was certainly far from perfect (and displaying as many dialogs as different errors on a certificate is definitely not something nice), it is still better than something not working at all.

For 10 days now, I've had ADSL problems. Basically, there is something fishy somewhere between my end and the DSLAM. That can be anything, and for the moment, all I can do is wait for either my ADSL provider or France Telecom, whichever is responsible for the problem, to fix this. Anyways, my network connectivity is sometimes working (though quite slowly, especially on uploads), but more often not, with sometimes connectivity for a few seconds (enough to download small files or pop mail).

The glandium.org server being behind this ADSL line, it means that you're probably not able to see this post. Or maybe a feed-reader/planet/whatever got it while the line was somehow working. Note I've been able to setup another MX server, so that mail sent to my domain go somewhere I can fetch them. Don't worry about sending me messages, they will reach me. Just that it may take time for me to be able to see and/or answer them.

Anyways, the main downside is that it makes it harder to handle the upcoming xulrunner transition.

On the other hand, the upside is that I finally could take some time to work on ext3rminator again, basically rewriting the code from scratch for reasons I'll explain when it will be ready for a release. It's good to see that some new APIs in libext2fs, added since 2002~2003, when I first wrote ext3rminator, make some of the work easier. It's still sad there is nothing to handle reading the journal. Not that it's difficult (though not documented much), but that would downsize my code some more ;).

Update: It seems to be back to normal.

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.

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.

... 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...