Author Archive

(Please wait after the first 45 seconds)

Thanks for the feedback on the xulrunner-1.9 packages I posted yesterday. They led me to find a possible fix for the issue.

Wasn't the package fixed? will you ask. Well, yes and no. Actually, it was built using the internal copy of cairo in the mozilla source tree. And this internal copy is (guess what) not vanilla. And we don't want to be using the internal copy because it's hell for stable security.

I took a deeper look into the changes and spotted something that looks like a workaround for exactly this corruption issue. So if people having the corruptions before installing the test package could downgrade to the current version in unstable (apt-get install xulrunner-1.9=1.9.0.3-1 should do), install the following cairo package: for i386 and for amd64, and tell me if the corruptions are gone, that would be very helpful :).

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

The Firefox EULA debacle is over. While this is nice, especially because they retracted, there are several things at stake here.

• Something is obviously fishy in all this. On one hand, Mark Shuttleworth claims:
  

  Mozilla Corp asked that (the EULA) be added in order for (Ubuntu) to continue to call the browser Firefox.

  On the other hand, Mozilla claims all over the place that the EULA text was a mistake. Couldn't they think more about what they're demanding from distributors before asking them stupid things ?

• It's not the first time Mozilla approaches a distro to ask them to comply to new demands, and create a controversy, a burden or a real PITA. What is going to come next ?
• From my bug reporter point of view, the way Mozilla handled it can be seen like this: when the Debian nutcases complain about the EULA being shown in "Open Source builds", it's not a problem, and the EULA is actually necessary. When bad press comes about the same EULA because the big player that Ubuntu is starts rebelling, it becomes an important mistake. I just hope this feeling is wrong.

Update: there is a nice article on the EULA issue on Groklaw.

Recent news are confirming that Debian's choice to not comply with Mozilla's trademark policy and rename Firefox to Iceweasel was a good one.

When the issue came up two years ago, most people focused on the wrong issue of Mozilla demanding to review the patches we apply, and while two years ago that would have been an actual burden, I must say they have improved in the last months on the patch review (and even inclusion) side. If they had changed the license for their logo (which was the actual uncircumventable problem), I might have considered changing the name back.

That would obviously have been a mistake, as Mozilla has found another creative way to badly behave. I'm so glad we chose the Iceweasel road.

Now, speaking of this infamous EULA, I filed a bug a while ago, because the EULA would also show up on unbranded builds, which was "resolved" invalid. Apparently, the main reason for keeping the EULA is because of the use of services that require an EULA, such as safebrowsing. The only terms related to this that I can see are:

5. WEBSITE INFORMATION SERVICES. Mozilla and its contributors, licensors and partners work to provide the most accurate and up-to-date phishing and malware information. However, they cannot guarantee that this information is comprehensive and error-free: some risky sites may not be identified, and some safe sites may be identified in error.

Does that really require to read the rest of the legal boilerplate ?

Everybody is talking about that these days, since information on Google Chrome leaked. But the fact is, this is what is going to happen with Google Chrome: stupid people proving that 2 + 2 = 5.

I haven't tried IE8 nor am I willing to, but one of the rare things I read about IE8 when people were discussing how not innovative Google Chrome was, is that it uses a process per tab.

Now let's assume IE binary code + libraries fit in 10MB (which is probably a small estimate), and you open 10 tabs. Here you are : 100MB RAM consumed. OH MY GOD!

Except that memory is shared between the processes. That's 100MB virtual memory.

Reality is that you'll have a hard time calculating the actual amount of memory used.

Update: It has already started.

There has finally been an official webkit release for the Gtk+ port, and I finally took the necessary time to package it.

As you can guess from the screenshot above, it now has plugins support.

It is also über fast. You can compare with previous results for both gecko and webkit.

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.

It seems some people don't like the new about:config warning in Firefox 3.0. The sad thing is this message was not intended to piss people off.

The localization note intended for translaters reads:

<!-- LOCALIZATION NOTE: aboutWarningTitle.label should be attention grabbing and playful -->

It's not even necessarily talking about warranty in other locales:

<!ENTITY aboutWarningTitle.label "Attention, danger !"> (fr)
<!ENTITY aboutWarningTitle.label "¡Zona hostil para manazas!"> (es-ES)
<!ENTITY aboutWarningTitle.label "Here be dragons!"> (en-GB)

Seems like the en-US version has a strange definition of playful.

While digging what was happening in bug #473557, I happened to get just in the right place of Iceweasel's code to fix the longstanding issue of it proposing "less" and other terminal-only applications as helpers for some MIME types.

The upstream bug is 6 years old.

The fix is 3 lines.

One of these lines is "}"

It will be in next xulrunner upload to unstable.