Performance impact by extensions

As suggested by recent the recent post, today I wanted to check the startup performance of my Firefox extensions.

The first step was getting the timing values, and I must say that it's really crazy how every project is always stating "it's easy, you just have to install this", and that means that you have to install php for one project, the different .net frameworks for another, other request Java, then the jdk, jre, ant, ...., in this case they say that you just have to install both Cygwin and Python in order to get the time!!!

I'm tired of installing things, so I opted to use the macbook and fortunately it seems that Python is already installed in MacOsX so I didn't need to install anything and after a few tests I got the timing values (although I wasn't sure about the unmount part and skipped that script because I didn't want to get a big problem).

Ok, around 1500ms with the default profile. So I disabled some add-ons and got down to 1000ms, wow, 50% improvement.

Then I checked both WriteArea and SendToPhone (the current as the next one that includes some drastic changes) and it seems that the startup time was similar, I didn't notice a performance hit due to enabling or disabling the extensions, and that's logical because they don't really do too much things at startup, just some listener for context menus, an overlay here and there,... but no heavy duty. That means that fortunately I don't have to work in order to improve the performance.

Finally I started re-enabling the rest of extensions and checking the times and the culprit for the 500ms hit is.... Firebug!

I don't want to say bad words about Firebug because it's really useful, but on the other hand it really needs some hard work with cooperation by the Mozilla guys to find out the issues and address them correctly.


Final UA for FroYo FRF91

There are no surprises in the User-Agent for the "final" build of Android 2.2 for the Nexus One

Mozilla/5.0 (Linux; U; Android 2.2; es-es; Nexus One Build/FRF91) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1

Again, the only change is the build identifier. I tested just in case the demo for contentEditable and it has the same problems, it's almost impossible to use. Even the trackball isn't recognized as a way to move the caret (that is invisible btw).


GoogleMaps for CKEditor 3 is almost ready

After lots of work to port all the code to the new architecture both of CKEditor 3 and Google Maps 3, the final version is almost ready.

The missing parts

First and foremost: there are three features available previously that won't be ready in this first version because they aren't available in the Google Maps 3 API and I think that it's better to wait for them to port them instead of doing some partial work that requires time and then it will be thrown away.

These features are:

  • Ability to create and edit lines and areas. Tracked in Issue 2432. In the first versions of the plugin (1.x) I coded some basic editing capabilities for lines showing fake markers, but I think that lot of us are waiting for the port of this feature and hopefully they can port it soon.
  • Option to show/hide the Overview Map at the bottom right corner. Tracked in Issue 1470. Ok, it's not really that important, so it won't be a problem for most of the people.
  • Option to show the Google search widget. Tracked in Issue 1697. It adds a nice touch to some pages, but it isn't really needed for most of the maps.

Of course my biggest concern is the editing of lines and areas. For the moment the editing dialog is able to load existing lines and areas from previous versions and change their properties (width, color, opacity), but not to edit their points. As a partial workaround you can use a KML file, but of course that requires the use of a program to create such file. The good thing about KML files is that they can contain lots of data, but if you want to generate a static image then this won't work (Issue 207)

With regards to the CKEditor side, the integration of the dialogs as elements inside the page and the default CSS provided makes it almost impossible to correctly show the maps inside the dialog: there's a CSS rule that tries to reset several values for all the content inside a CKEditor instance, but the way that it's written breaks the CSS inheritance and only the styles that are applied to one element are shown correctly, it can't inherit things like text-align or cursor from its parents, and any <input> that you try to insert doesn't have the default OS styles (in fact it doesn't have any border or background at all).

So some elements that previously were shown inside the map as info windows (text, lines and areas properties) now have their own CKEditor dialogs because it was a nightmare trying to put the controls in a simplified UI.

But despite moving those controls to their own dialogs, there are still some visual problems with the maps: the drag cursor isn't shown, the pointer cursor is instead a text cursor, all the texts are aligned to the left...

The good things

So those are the bad news, let's see the nice side of the changes

The Maps API v3 doesn't require to sign for a key, so that's one step less to worry about, and it can help a lot if you host your site under different domains.

The overall speed is improved, both GMaps and CKEditor APIs are part of the improvement as they have been redesigned to improve performance. Also, in CKEditor the dialogs aren't any longer a new iframe, so they share the same scope with the page, and once the GMaps API has been loaded it doesn't require another check when the dialog is launched again.

I've been trying to reorganize some parts of the code in order to have a better base planning for future enhancements (I won't make any statement about what or when because they might be a distant future),  but now the code should be easier to make some kind of improvements.

Some little bugs have been squashed, but for the moment and until it's tested in more environments it can include unexpected problems. An example of something that I didn't ever test previously but now I think that it will work (I'll try to test it correctly) is having two editor instances in the same page and editing the maps in one or both of them.

What's left

I've ready almost all the code, now it needs to be tested more thoroughly, tested across some browsers (no, I won't care about old versions), test that it reads correctly data from the previous versions of the plugin.

Also it needs to try to improve the UI in the dialogs, they way that they are done in CKEditor makes it a little harder to get nice results, but I think that I'm finally getting the grip about that and with some tricks it's getting better, although I won't be happy until I really see that it works as expected and not some "it's not too bad".

Then the basic documentation, how to install the plugin and some user docs, I hope to reuse as much as possible from the previous version.

And then it will be finally ready (I guess that in a week from now).

No, it won't be open source. As the v2 of the plugin this one will be available only under a license, people that collaborated for the previous versions will get this one shortly.

With regards to v2, once v3 gets all the missing features I will provide it for free 3 months after the release of the updated v3 version. I don't see any reason to keep that code locked for ever if it has been deprecated by a newer version.


FormData interface won't be available for IE9

Not long ago a new DOM interface to send form data with XHR was introduced "FormData", and as shown in this post from the Mozilla guys it can be useful to provide nicer integration for uploading files to the server.

That option is already available in Chrome 5 and Safari 5, Firefox 4 will also support it, (Opera?) so I wanted to ask for this to the Microsoft IE team and filed this ticket, but just today they have replied that they won't be able to support it in IE9.

Does Android 2.2 support contentEditable?

In Android 2.1 the browser doesn't support the contentEditable attribute for elements, meaning that it's not possible to use WYSIWYG editors in web pages because the virtual keyboard won't popup to write your texts (lots of other operations can be done by manipulating the DOM, but also providing a virtual keyboard might be too much).

One important problem with that status is that although contentEditable doesn't work, isContentEditable does return the "correct" value, and it states that such elements are editable although they aren't so it can't be used to find out if the browser doesn't support contentEditable and when they release a new version enable it automatically.

So I filed a ticket about this some weeks ago, and yesterday I got a notification stating that Android 2.2 a.k.a. FroYo does support contentEditable!

Those are good news, really good news. If it's true, you can expect to see support for your Android phone shortly in editors like CKEditor, TinyMCE, YahooUI,... and apps like GMail, Google Docs....

Anyway, I'm still unsure about that statement, currently I'm using FRF83, that's not the final build because now I'm waiting for the OTA as they said that we should get it during this week, but I've been doing quick tests with the previous builds and I didn't notice any change in the behavior.

You can test it right below. If it works, clicking after the "type here" paragraph should put the caret there and enable the keyboard, and clicking the link should not open the Google home page, let me know if it works in your phone.

Type here.., a link (it's part of the content, so it shouldn't be active)