Asus Eee Pad Transformer

These days I'm testing an Asus Transformer (the first version, not the new "Prime") in order to check the viability to use it as a kiosk display.

Currently it's much simpler and cheaper to provide the clients or visitors a touch screen so they can query information or perform some basic tasks thanks to all these new tablets, but the fact is that it could be even cheaper and more powerful. I'll write a separate post about that with all the things that I have in my mind.

I'm gonna try to focus this little review on the things that I've found so far, at least as a serie of notes to myself so I can remember these details some months from now.

The client wanted basically a touch screen that could be used to access a single site by the customers so things like GPS, bluetooth or the cameras didn't really matter, but it's usualy better to get a brand name instead of an unknown mix  of components that you can't be sure if they will survive 6 months and the quality of those components. And of course, having such a table available means that they could take it home at night and use it for other means if they want to :-)

I've also thought about buying one such tablet for myself, and I was unsure about how I might use it instead of my Nexus One (N1), so this is a good way to test it.

First impressions

I was expecting/hoping for something lighter. I don't mean in any way that it's heavy; not at all, but for myself I was hoping to get a very light tablet and this one doesn't fit that expectation. I wanted something as light as my phone but with a bigger screen, hey, we're free to have high hopes for the future :-) maybe a 7" tablet might be better for my expectations in this regard.

It has a relatively wide bevel around the screen, in a way it can prevent that grabbing the borders will activate the touch sensors like happens in the N1, but I think that other smart touch controlers don't have the same problems as the one in the N1 and even then I bet that you can cut that border in half and still keep always the fingers out of the screen.

It uses a propietary connector instead of mini or micro USB, I don't like that; we all know that in such situations the outcome is that if for whatever reason the cable gets damaged or lost I have to buy it from them instead of being able to use any other one that I have available at home. Other simple reason is that the cable itself it isn't very large so if I connect it to the computer I can't move too much the tablet because it's almost at the full length of the cable.

It seems that trying to charge it by connecting it to a computer it's too slow according to other reviews. I've just connected it to check that but I can't be sure if it's charging or not, I don't see any indication like it happens in the N1 where an orange LED signals that it's charging and when it turns green then it's over 80%. But here there's no feedback about the charging, the only way to know that it has been charging is to wait a while and then look at the battery stats to verify that they have gone up.

I can understand that a power outlet is a better energy source than the USB connector of a computer, but if I buy a tablet I would expect to be able to connect it with a standard USB cable to a computer and then get it to charge at a reasonable speed instead of being forced to carry that special connector and wall plug.

Currently I can't use the tablet because it's charging from the wall and as I said the cable isn't very long so I would have to stay in an awkward position in order to use it while charging. BTW: when charging from the power outlet the Lock screen stated that it was charging, but after the screen goes off there's no LED, the only way to know if it has finished charging is to wake it up and look at the text in the lock screen.

Shortly after booting it up and connecting it to the wifi it downloaded two firmare updates automatically and the next day I performed a check while looking at the settings and another one was ready to install. I think that according to other comments Asus seems to be providing constant updates and that's a very good thing for me as a consumer, I don't want to buy anything from a company that sells a product and the only update that they offer is to spend the money with their new device. If I buy something I expect it to work and being supported for a very long time, I don't like that programmed obsolescence situation created by the big corporations to keep us buying new things.

Back to updates, the Market app notified that there were 4 updates available, although they show the Install button insted of update. I've managed to install/update one of those apps, the other three just open the existing app instead of installing a new version. One of those apps is Google Maps, it has the version 5.10.1 and the latest found with the N1 is 6.0.3. No matter how many times I click on the install button, it always open the current one instead of trying to upgrade it.

Talking about maps, it's quite broken in this version: while using only the maps view it seems to work fine, but after adding the satellite layer it hangs up in a very short time, the map gets frozen and although the buttons seem to accept clicks, there's no dialog, dropdown or anything. The only solution at that moment is to go to the Applications settings and kill the Google Maps process. But the funny thing is that once I launched the maps while in Airplane mode and then I was able to use the satellite view with the cached photos perfectly, zooming in and out, moving, rotating, ... really nice but it's not practical to go into airplane mode in order to use the app :-D

The YouTube application doesn't show the subtitles, although it's able to dim the controls (and clock) in the notification bar so they are a single gray dot . So far I've found that only the Gallery is able to perform this same trick, so using other video players not optimized for HoneyComb might be a little annoying with thosee controls always visible while trying to watch a movie.

The Browser uses the following User Agent:

Mozilla/5.0 (Linux; U; Android 3.2.1; es-es; Transformer TF101 Build/HTK75) AppleWebKit/534.13 (KHTML, like Gecko) Version/4.0 Safari/534.13

It looks more like a Chrome thanks to the full url bar with tabs, and the first thing that it prompted upon launch was to install the Flash Player from the market (I didn't because I don't need it for this project), besides tabs, the browser also supports incognito mode.

contentEditable and CKEditor

I performed a quick test and looked OK, so I used my local copy of CKEditor these are my tests (the tablet is running Android 3.2.1 HoneyComb, the browser doesn't seem to be a version modified by Asus but I can't be sure about that), you can use the official CKEditor demo as well:

The keyboard pops up automatically and the blinking caret is visible. It's easy to write (using always the virtual keyboard, I'm using the default Asus keyboard for these tests), but it's hard to move the caret exactly, there are no cursor keys and you have to rely on touching with your finger in the right point.  When I tested in the simple contentEditable test, each time I pressed Enter the keyboard went away, but in CKEditor this doesn't happen, I guess that this is an unexpected benefit of the enter key handler in CKEditor. Another difference is that in the basic test the browser follows the link but in the full CKEditor nothing happens, so I wonder what can be going on here.

It's possible to perform a long press and select the text in the content as well as copy it, but the text can't be pasted back in the document directly. If I press the "Paste as Text" then I can use the dialog to paste in that textarea and insert it back in the document (but of course as plain text). So: No pasting in contentEditable.

Those selection handles don't seem to really work at the DOM level, if I try to select some text and then apply any formatting then nothing changes: the handles go away and the text remain in its previous formatting. It's not possible to format existing content. The problem seems to be that those handles are overlayed on the document, but they don't modify the DOM selection: It's possible to select all the contents with the "Select All" command and the selected text gets a green background, then performing a long touch shows the selection handles that allow to perform a new selection over the existing content that it's already selected. Then clicking the Bold button the first time makes the handles disappear and the second one made all the contents bold as the previous "Select all" was still in effect.

Clicking a format button like bold and then typing works correctly, the text uses the format so it can be used to format new content; but of course you have to be careful to click/touch the right button, the current toolbar isn't designed for a touch screen.

Dialogs can't be dragged around (like iOS), of course the dialogs can't be resized and the tableresize plugin doesn't work. When all those elements are fixed to handle touch events for iOS they should also work in Android. Another point in common is the lack of context menus, this is all part of adjusting the UI of CKEditor to make it touch friendly. Trying to use the divreplace sample also fails, the sample might need to use the proper listener instead of the current doubleclick as that just zooms in-out

The maximize button makes the toolbar disappear making this a very dangerous button.

Some differences with the iOS tickets: I didn't notice any problem typing after enabling SCAYT, the editor doesn't grow, it remains at the initial size,  overflow auto seems to work, it's possible to scroll the contents of the editor as well as the toolbar combos

The toolbar combos can be closed , but they don't work perfectly; selecting an option from font size or family works, but it also performs a click on the point where you touch the screen to select the option, so usually the caret moves and you don't get the expected result. The Styles combo is much more buggier, although the contents scroll but dragging them, it seems that somehow the clicks always go to the first items, I always ended with "var" and "kbd" instead of any other style further down.

When a dialog is opened, it puts the caret in the first field, but the keyboard disappears and you have to touch that input to show again the keyboard.

When typing at the end of the editor and pressing enter the caret jumps to the next line, but the content doesn't scroll up automatically so you can't see what you're typing, and when I tried to write something long, it scrolled the first line, but it didn't scroll again after that. When I tested the Google Voice keyboard to talk instead of typing it only inserted the first letter of my sentences.

Using the editor with the default sample pages isn't nice because the editor is placed almost at the bottom of the screen, when you touch the content the keyboard pops up over the current content so you have to scroll now that up (previously it wasn't possible) to see the caret. and whenever the keyboard goes away the document is scrolled back to its original position and a loop begins of keyboard on, scroll manually, keyboard off, auto scroll. And when a dialog opens up you might not be able to use it correctly in landscape mode because the dialog is centered on the screen, it's not possible to scroll it and the keyboard is covering most of the dialog

CKFinder doesn't recognize the browser as a mobile device so it doesn't show automatically the little adjustments introduced in 2.1 and that means that it's not possible to insert images or links to files.

Google+ vs Blogger

Ok, according to the latest announcement it seems that the aim will be to keep Blogger and use Google+ to share existing content outside and comment on it.

Just a little post to test it :-)

 

Google Maps plugin with lines and areas

Version 3.1 of GoogleMaps plugin

Finally after all a very long wait I can say that the Google Maps plugin for CKEditor is ready, it includes all the previous features and uses the latests versions of both CKEditor (3.6.2) and Google Maps (3.7)

As I explained in previous posts the main missing feature was the ability to create and edit lines (paths) and areas and recently Google added this missing API. So after founding a little free time I've included these features as well as checking and testing everything fixing some little problems along the way. (One such problem is that previously I think that CKEditor managed to automatically resize the dialogs to fit their contents, but now they are shown beyond the dialog boundaries. Some people have reported such problems when they try to add a lot of images to the Smileys dialog).

A summary of features

The plugin allows to insert a Google Maps into your pages easily without any previous knowledge.

It's possible to use any size for the map, while you're in editing mode a static preview of the map is shown (if the size is bigger than 640x640 px the image is scaled because that's the maximum size for static maps)

A preview/edit dialog is used to move the map as desired as well as setting the zoom level or various features like map types or available controls.

A search field is available to find the location that you want.

It's possible to add several overlays on the map like markers, text, lines and areas. It's also possible to use a KML or KMZ file to add complex sets of features after creating it with Google Earth for example.

The plugin can generate either static images, normal javascript maps or static images with the option to turn them into normal javascript maps. (the static image doesn't support the same set of features than the full map: texts and Kmls won't be shown)

How to get it?

Please, use the main page of the Google Maps plugin for CKEditor.

Deprecation of old browsers or bad pages

I would like to use this message to announce that from now on this plugin as well as any other that I develop won't support pages in Quirks modes and versions 6 and 7 of Internet Explorer.

This means that I won't test any plugin in those cases, and if someone reports a problem with such situations then the output might be that I add a check so that the plugin refuses to load instead of spending several hours to find a workaround for such problems.

Of course, the visitor of the page will be able to view the map correctly with any browser (until Google decides to pull the plug for those browsers), but when the admin is trying to edit the content he should use a modern browser and your administration should use a Standards rendering mode.

Edit 6-december-2012:

A summary of new features since 3.1(like compatibility with CKEditor 4) can be found in this post.

Write Area 1.1 discussion

Seems that some people don't like the new integrated mode of Write Area, so I would like to know better what's the problem and what can be done to keep everything simple and useful for as most people as possible.
First, I've added a survey at the side pane. Of course, remember that we are talking just about the textarea replacement; if you're using it to replace an existing HTML editor then this survey isn't for you because there's no integrated mode in that situation. In the survey you should be able to check more than one option if you think that you would use more than one mode if all there were available.
So far the complains have been about the removal of the option to edit in a popup dialog, I didn't read anyone complaining about the removal of the bottom pane and at least that's a good thing. Can we all agree that the bottom pane isn't needed?
Then the dialog thing. Why are you having problems with the new mode and need the dialog back?
Please, write a comment here explaining (in a civilized way) why the integration mode doesn't work for you. I've got one comment about problems in tumblr.com, I'll try to check that tomorrow, although I'm not sure if I'll have enough time as I had planned other things to do.
But if you provide a list of things that don't work as expected then I can try to look at them and then fix them one by one or bring back the dialog if they can't be fixed in integrated mode.
Now it's your turn if you want a change in this extension.

Toolbar buttons in Writearea

Since version 1.1 it's possible to configure which buttons do you want to use in the toolbar of Writearea. There are in fact two toolbars and you can switch between them with a custom button.

The way to define the buttons is to use the preferences pane of Writearea and put the array of buttons in the corresponding input fields. Note that to try to help a little, you don't need to put the outer [ and ], just the groups separated by commas and with a '/' if you want to start a new row.

These are the default values for each toolbar:

Full Toolbar:
['Save'], ['SaveFile','LoadFile'], ['Source'],['Cut','Copy','Paste','PasteText','PasteFromWord'],['Undo','Redo','-','Find','Replace','-','SelectAll','RemoveFormat'],['ShowBlocks','Maximize'],['Image','Flash','Table','HorizontalRule','SpecialChar','Iframe'],['JustifyLeft','JustifyCenter','JustifyRight','JustifyBlock'],['BidiLtr', 'BidiRtl' ],'/',['Styles','Format','Font','FontSize'],['Bold','Italic','Underline','Strike'],['TextColor','BGColor'],['NumberedList','BulletedList','-','Outdent','Indent','Blockquote','CreateDiv','Code'],['Link','Unlink','Anchor'],['SwitchToolbar']

BasicToolbar:
['Undo','Redo'], ['Bold', 'Italic', '-', 'NumberedList', 'BulletedList', '-', 'Link', 'Unlink'],['SwitchToolbar']

Most of the commands are the ones available on the default CKEditor install, I don't know if there's any listing of the meaning of all of them, the best thing that I can think of is the user's guide, but it doesn't clearly link the button names with its action.

But beyond those common buttons, there are a few ones with special meaning here:

Custom buttons

'Save': It's available only while in the dialog popup, it will save the content of the editor to the original element. When the editor is integrated into the page you should use the existing save button provided by the page, that way there won't be any problem due to extra event handlers or differences between Save draft, Publish and Preview buttons of the page.

'SaveFile', 'LoadFile': These two options allows you to save/load the content of the editor to a file in your computer, just in case the page doesn't have any auto-save feature or you want to use something more than once.

'SwitchToolbar': These button allows you to switch between the basic and the full toolbar. I would suggest you to use the basic toolbar by default and only switch to full toolbar when there's something extra that you need at that moment. And of course, adjust each toolbar so the basic includes the commands that you usually need and the full toolbar doesn't includes buttons that you know you'll never use.

'Code': it's the SyntaxHighlight plugin available here. I made some little adjustments, but someday I might have to perform some bigger fixes to improve it and make it easier to use.

 

ServerPreview plugin for CKEditor

Some years ago I created a plugin for FCKeditor to easily provide a preview of the contents that are being edited as they will look in the final site. That's specially important when you're using special markup in the editor that it's being replaced at the server by a widget or just some plain data.

The plugin is quite simple as the idea itself is simple: Get the current contents, and instead of opening a window with that HTML, post it to a custom page at the server and that page will be the one that can provide the proper context and show the HTML as  it will be rendered in the final page.

This weekend I was tasked by Flatbooster GmbH to upgrade it so it can be used with CKEditor, and also perform some additions like controlling the size of the preview window.

The usage is quite basic, you just have to add it to your extraPlugins, specify the serverPreview_Url with your server script and use the posted "htmlData" variable. You can read the install.html to learn about other little options.

The plugin replaces the normal 'Preview' button, so there's no need to do anything to your toolbar.

The plugin can be downloaded here: Server Preview plugin for CKEditor 1.4.

Update 15/10/2011

Version 1.4, allow to use other CKEditor instances in the serverPreview_AdditionalFields setting.

 

 

Is your clock adjusted correctly?

FoxToPhone now uses OAuth

In July I changed the authentication routines in FoxToPhone to start using OAuth like the latest version of ChromeToPhone. Using OAuth in a Firefox extension was a little harder at the start because I couldn't find something easy to use like the snippet that it's available for Chrome extensions.

Finally I took that code and adapted it to be able to use it the way that I wanted, without the need of a "background page", and reusing most of the code to avoid introducing any unexpected error.

This weekend this version 1.2 of FoxToPhone has been approved and now it's being updated as Firefoxes check for updates of the extensions. And despite all our hopes on the beta testers it's clear that not everything is OK.

Some people have been experiencing login problems with ChromeToPhone getting a hardly useful "redirecting..." message, and it's not clear what's going on, so it should be expected that some people would get also strange errors in Firefox with the new authentication. We fixed one or two such issues during beta testing, and today I've found another reason.

Your clock settings

Other people have already commented about it in that ticket, and I didn't look at it, but today one user reported login issues and after a little testing I found that while starting the authentication, one request is done that includes the current time, and in this case the request showed that it was one hour ahead of the current time. And the Google server replied with an status 400 meaning that the request was wrong.

So the user just moved his clock one hour back and then he was able to login and start sending the requests. Great!, we're moving ahead.

So if you get a response status 400, then you should check the settings on your control panel about the time zone and daytime savings are correct. Even if you see that the clock matches the one in your wrist, the computer also has additional information like the zone/country where you are, so when it tries to convert that local time to a global timestamp it will generate the wrong data if some of your info is wrong.

Testing time

This is a little script that tries to request the current time to the Yahoo servers and then checks it with your local time, if you see an error message then you should review the time settings in your computer

 

Hey Google, can you improve that error page?

Certainly returning "400 (Bad Request)" when the problem is the timestamp seems a little rude. It's clear that it's possible to check that the parameter is out of the allowed bounds, so in order to be helpful the error message should give a clearer hint that the problem is just that parameter. No real attacker is gonna try to send a request with that parameter wrong, it's just too easy to do it right, so the only people that would pass wrong data there are those users that don't realize that there's a problem with their clock settings.

Just as I've been able to mock a little script that performs a simple test, I guess that you should be able to provide at the very least the same check in a dedicated page and working a little further it should be able to guess more exactly if the problem is the time zone, the DTS or just the clock itself, something that shows the user the correct screenshots to check their settings etc...

 

Location aware password policy

This morning I waked up and I was thinking about the password on my phone. I've always found it annoying having to retype it every now and them, specially if I'm at a place like my home where no one else can grab it.

So I thought that the device should be smarter, and I think that currently it should be possible to bring a little intelligence to these "smartphones". When I'm at a place that I have to configured to be trusted, then once I unlock the phone it should remain unlocked as long as it remains there or I don't explicitly lock it.

One easy way to achieve this would be to enhance the wifi manager, whenever I connect to a protected wifi with a password one new option is available: "this is a trusted site", by checking it the phone (or any similar mobile device) will remain unlocked and it's also possible to specify if the unlock should last some minutes (5 or 10, like when you are doing something with 2 devices, leave one apart and when you pick it up again it's locked so you waste time unlocking it), one hour or remain unlocked as long as you're connected.

That simple change could help lots of times, if we can use the devices at home without the need to retype the password (or whatever lock mechanism you've chosen), then we would be slightly happier and we could use slightly harder passwords for the moments when we're out of home.

Additional refinements could defined as an option to specify a coverage zone: instead of home, you're at work in your office, so you want the device to remain unlocked while you're there, but if you move out of the office then it should go back to the normal behavior.

I think that many people might not be using currently any password just to avoid the hassle of having to unlock his device every now and then, but if a system like the proposed in this post would be available then I would bet that they would be much happier to know that they have a secure device when they're walking down the streets while keeping the simplicity of an always available device at home without the need to retype the password at every moment.

 

Upcoming changes for Write Area

It has been a long time, but these days I'm going to try to push a new stable release of Write Area. It will be mostly an upgrade to the current CKEditor 3.6.1, but at the same time I'm gonna try to finish some code that it's available in the betas and provide a simplified version.

The main change will be the removal of the option to select whether to open the editor in a bottom pane or in a dialog. My plan is to finish the behavior of the new "integrated" mode, so that whenever you select to use Write Area with a normal textarea then it will be replaced by a CKEditor instance integrated in the same page. This is similar to what the "bottom pane" provides, but with the advantage of being able to create more than one instance, and the rest of the scripts of the page can get direct access to the contents as if nothing had happened.

If you try to use instead an existing editor that isn't too compatible with the current Firefox or it's missing features, then the editor will be launched in dialog mode. The plan is to do this automatically without the need to select a preference.

Why?

First: Simplify options.
More options means more testing, harder for the user as he has to think about what's better. I can't claim that I know better than him what's better for him, but I know what's more job for me.

Second: Try to avoid future problems due to changes in Firefox.
The bottom pane is a "XUL overlay", that means that it's somehow quite integrated with Firefox, and in the future the plan is to try to move as much extensions as possible to the Addons-SDK. That means that such integrations might be harder or just impossible. If I start removing these blocks I can try to test if it's possible to port the extension to this new world. Anyway that goal is quite far away as I've stated previously that I won't start using the Addons SDK as long as they require to install Python or any other third party libreary/compiler/whatever.

Third: Other browsers.
By using a simpler approach it's possible to create a Write Area version for Chrome, and although I don't use it I understand that other people do, so if there are just a few differences then I can provide a port of the extension. It won't be as feature rich as the Firefox version, but at least is something that people can use.

Conclusion

If you have a strong reason to believe that I'm making a mistake the I would like to hear your concerns. Otherwise I'll go ahead and release the update when it's ready

Third version for seamless replacement of textareas

Sometime ago I wrote a script that allows to use CKEditor, and at the same time keep using older scripts existing on the page that relied on reading the textarea.value (or even writing it), without having to modify them to use the CKEditor API.

The initial version worked with Firefox and Internet Explorer 8, and shortly after I added some adjustments so that Opera was also supported.

Recently a comment in that second post stated that the script gave errors in Chrome, although it tries to detect if the API that I was using is supported, but of course, webkit guys decided to implement the API but not make it available for native properties. Their statement is that treating native properties as overridable would have a negative effect on performance, and as we all know it's much more important to have a fast browser than a browser that allows the developers to do new things; unless you're in their team then you can write a new API for whatever you need and everyone else should use this API because it will change the world, you'll no longer have to use Flash because now you have this API to overcome other problems that we didn't want to fix. Besides the bug tickets commented previously, here's another one: bug 36423

Ok, enough ranting.

As I said, I've worked to find out the problems and the funny fact about this new version is that it works in Chrome but it still fails in Safari 5.1. So you can use it in your site if can restrict the browser used by your users to IE8+, Firefox 3.5+ , Opera 10+, and Chrome 12+ (I don't really know the oldest version of Firefox, Opera and Chrome where this will work, but I wouldn't expect anyone to use old versions of those browsers)

// Modify the default methods in CKEDITOR.dom.element to use .nativeValue if it's available
CKEDITOR.dom.element.prototype.getValue = function()
{
    if (typeof(this.$.nativeValue) == "undefined")
        return this.$.value;

    return this.$.nativeValue;
}

CKEDITOR.dom.element.prototype.setValue = function( value )
{
    if (typeof(this.$.nativeValue) == "undefined")
        this.$.value = value;
    else
        this.$.nativeValue = value;

    return this;
}

// Hook each textarea with its editor
CKEDITOR.on('instanceCreated', function(e) {
 if (e.editor.element.getName()=="textarea")
 {
  var node = e.editor.element.$;

  // If the .nativeValue hasn't been set for the textarea try to do it now
  if (typeof node.nativeValue == "undefined")
  {
   // for Opera & Firefox
   if (!DefineNativeValue(node))
   {
    // IE8 & Webkit
    if (!DefineValueProperty(node))
    {
     alert("Your browser is buggy. You should upgrade to something newer")
     return;
    }
   }
  }

  node.editor = e.editor;

  // House keeping.
  e.editor.on('destroy', function(e) {
   if (node.editor)
    delete node.editor;
  });
 }
});

// This function alters the behavior of the .value property to work with CKEditor
// It also provides a new property .nativeValue that reflects the original .value
// It can be used with HTMLTextAreaElement.prototype for Firefox, but Opera needs to call it on a textarea instance
function DefineNativeValue(node)
{
 if (!node.__lookupGetter__)
  return false;

    var originalGetter = node.__lookupGetter__("value");
    var originalSetter = node.__lookupSetter__("value");
    if (originalGetter && originalSetter)
    {
        node.__defineGetter__("value", function() {
                // if there's an editor, return its value
                if (this.editor)
                    return this.editor.getData();
                // else return the native value
                return originalGetter.call(this);
                }
            );
        node.__defineSetter__("value", function(data) {
                // If there's an editor, set its value
                if (this.editor) this.editor.setData(data);
                // always set the native value
                originalSetter.call(this, data)
                }
            );

        node.__defineGetter__("nativeValue", function() {
                return originalGetter.call(this);
                }
            );
        node.__defineSetter__("nativeValue", function(data) {
                originalSetter.call(this, data)
                }
            );
        return true
    }
    return false;
}

function DefineValueProperty(node)
{
    var originalValuepropDesc = Object.getOwnPropertyDescriptor(node, "value");

 if (!originalValuepropDesc)
  return false;

 // Safari doesn't allow to overwrite the property (but Chrome does)
 if (!originalValuepropDesc.configurable)
  return false;

    Object.defineProperty(node, "nativeValue",
            {
                get: function() {
                    return ( originalValuepropDesc.get ? originalValuepropDesc.get.call(this) : originalValuepropDesc.value );
                },
                set: function(data) {
                    originalValuepropDesc.set ? originalValuepropDesc.set.call(this, data) : originalValuepropDesc.value = data;
                }
   }
        );

    Object.defineProperty(node, "value",
            {
                get: function() {
                    // if there's an editor, return its value
                    if (this.editor)
                        return this.editor.getData();
                    // else return the native value
                    return this.nativeValue;
                },
                set: function(data) {
                    // If there's an editor, set its value
                    if (this.editor) this.editor.setData(data);
                    // always set the native value
                    this.nativeValue = data;
                }
            }
        );
 return true;
}

// Detection, not really needed, but it can help troubleshoting.
if (Object.defineProperty)
{
    // IE 8 and updated webkits
 // Detect Safari
 if (document.head)
 {
  var test = Object.getOwnPropertyDescriptor(document.head, "innerHTML");
  // IE9
  if (!test)
  {
   if (!DefineValueProperty(HTMLTextAreaElement.prototype))
    alert("Unable to define property override on the prototype");
  }
  else
   if (!test.configurable)
    alert("Safari doesn't allow to overwrite native properties");
 }
}
    else if (document.__defineGetter__)
{
    // FF 3.5 and Opera 10
 // We try to get the innerHTML getter for the body, if it works then getting the value for each textarea will work
 // Detect old webkits
 if (!document.body.__lookupGetter__("innerHTML"))
  alert("Old webkits don't allow to read the originalGetter and Setter for the textarea value");
}
    else
{
    // detect IE8 in compatibility mode...
    if (document.documentMode)
        alert("The page is running in Compatibility Mode (" + document.documentMode + "). Fix that")
    else
        alert("Your version of IE is too old");
}

 

Too many permissions for simple apps

Yesterday I was badly surprised when Reto Meier added a post pointing to an Android game activated by the voice; that sounded fun (although it's clear that it can't be played in too many places), but I wanted to check it out.

The bad surprise came when the market showed me the required permissions for the App:

• Record sound (obviously, it needs as that's the differential point)
• Full internet access (ok, some ads as it's a free app)
• Read and write the contents of the SD card. This isn't too nice, but some apps and games have extra downloads to keep the app itself smaller and they download the data to the SD. We have to accept it until Android provides a better option (check below for my proposal)
• Read identity and state of my phone. No, this isn't OK. An app doesn't really require to know anything about my phone. Usually this is enough for me to not install an app.
• Read SMS. What??? Read my SMS? for a game?, are you joking?. So this app requires full internet access, read all the content of my SD card as well as my identity and my SMS? They can ask for my bank account at the same time.
• Send SMS. Ok, this is enough. What's the difference between this game and those trojans that have been found claiming to be legit Android Apps? How can a user be able to find out that the developer is really a good person and it's requiring those permissions really based on real requirements instead of being used to send premium SMSs and hide them as those trojans do?

Whenever such application with those huge permissions is mentioned by someone that it's otherwise respected, we can expect that people will download it, and by doing it people will be used to accept that apps might require extra permissions. This will lead to "permission blindness" just like people is now blind to the Ads that appear in some webs, people will get used very soon to the fact that any app might want to read your SMS, your contacts and anything else.

So this will destroy any effectivenes of the permissions system, the typical statement "be careful about what you install" and "it's easy to spot a trojan due to its permissions" will be void. Sum it with the lack of review system in the Android Market and you get a big problem just waiting to happen.

According to some comments in that post, the developers answered in Twitter claiming that the SMS is to upgrade the app to a paid version. So... what's wrong with the Android Market? why don't you offer the full version there instead of using SMSs? Does premium SMS work across countries? how much it's gonna cost some random user in Spain like me a premium SMS sent to the USA? If it's just an internal switch in the app, why isn't this done using the existing internet connection? People pay it in your site and then the app is upgraded to full version. Hell, it can even be done showing the user an unlock code and without internet on the phone app itself!

The requirement to read/write the SD card could be fixed if Android had a better system for apps to store their own data:
Currently those apps create random folders anywhere on the SD card and they remain there after the app has been removed. If instead of getting full access to the SD card they had access to just a custom unique folder, then this could be much better:

1. Any app can read/write to his own folder in the SD, ex. /Android/data/com.google.android.apps.maps/
2. That folder is only accessed by that app (or other apps like file managers that really request full SD access), there's no need to state it in the permission list
3. When the app is removed, the uninstaller also cleans up that folder, so that the app has been really uninstalled and nothing remains. If the user wanted to keep the data he can do a backup of the folder before performing the removal.
4. In summary: the app itself doesn't really need to know the location of that folder, it just knows that it can safely read and write there, and due to that safety it doesn't require an extra permission at install time. Better for the developer, better for the users.

The Android system really needs an improvement in the way that permissions are granted, the user shouldn't have to worry because an app is requesting weird permissions, also, the Android Market should be much more careful and force a review of any app that requires permissions like send SMS, or perform a combination of read SD and get internet access. When an app just requires internet to show ads it's OK, but if that app is also able to read all the data in your SD card (photos, Titanium backups, etc...) then it should be reviewed to provide a warranty that it's a good app and not something evil.

Enough of bad comments, do you want to know a nice game? (no, this post isn't sponsored and I'm not related to the developer)
Test Trap!, it ask for all the permissions that you can expect from a nice game: none, and it can keep you playing it for a while trying to beat yourself.

 

Testing Google's Music Beta

Last week I got the invitation to the new Google's "Music Beta" service. I haven't had time to test it too much, but these are my first impressions:

1. Upload is really slow. That's of course due to my ADSL connection, but you can expect almost a week to upload all your music.
2. It's strange that the limit is the number of songs (20.000) instead of the size of them
3. The Uploader recognizes that .ogg files are music, but it refuses to upload them. Why? I've to verify if it has uploaded other "strange" formats that Foobar2000 played happily.
4. I didn't had all the music properly tagged with ID3 as it was organized with folders and it worked fine, but now those files have crypting names. That's bad in a thousand files library. But the problem is that I have to find out which files have been uploaded wrong, then correct my local copies and also correct the remote copies (or reupload them).
5. If I edit the metadata of some remote file, I can't download later that updated file. That means that we can't really get rid of our local copies and use just the cloud for storage. In no way I'm gonna get rid of my MP3 player until the phone's batteries last as much and the only way to put music there is with USB, no magic cloud connection.
6. Some albums are missing the cover picture, and you can edit that with the web interface, but they have forgotten to add drag&drop support to easily upload the new picture. Hey Google, ask the GMail team to give you a hand.
7. I don't see how playing streaming music in a browser can be interesting in my desktop, I won't use Google Music there until they provide a native application that can use my existing files without streaming them (Hey, I already have them here)
8. The uploader has given me an interesting error with some files: "No music found in file", but every other player handles those files correctly. Editing the tags didn't fix, so I reencoded and then it accepted them and they were uploaded.
9. Other times it has stated that there's an error while uploading, so I have to verify album by album if it has been correctly uploaded.

 

Como usar el DNIe con Firefox 4 en Mac 10.6

This post is in Spanish as it's related only to a problem in Spain with Firefox 4.

DNIe vs Firefox 4

Desde que se lanzó Firefox 4 la gente que usa Mac ha tenido problemas para poder usar el DNIe ya que no permite instalarlo, y si lo tenías instalado con anterioridad no hace nada al intentar acceder a páginas donde lo requieran.

En principio nadie sabía indicar cual era la causa de estos problemas, pero tras crear un ticket en Mozilla respondieron diciendo que el problema es que estabamos intentando usar unas librerías de 32 bits y Firefox 4 se ejecuta por defecto a 64 bits.

Existen los drivers de OpenSC para Mac a 64 bits, pero no sirve de nada instalarlos, ya que los drivers específicos para el DNIe no vienen incluidos y la versión que proporcionan no funcionan con ellos, por lo que tenemos que esperar a que nos publiquen una versión oficial para poder usarlo correctamente.

Solución temporal

Sin embargo, en vez de desinstalar Firefox 4 y volver a la 3.6, podemos configurar fácilmente el ejecutable como indica Willyaranda para que se ejecute a 32 bits y de esa forma sí que podremos instalar la librería necesaria en Firefox y luego usar el DNIe.

Primero vamos a "Aplicaciones" y en el icono de Firefox pinchamos con el botón derecho y escogemos "Obtener información"

En esta ventana se activa la opción de "Abrir en modo de 32 bits"

Y ya está, ahora cuando ejecutemos de nuevo Firefox funcionará en modo de 32 bits y los drivers del DNIe sí que se ejecutarán. Podemos lanzar la web de verificación y nos pedirá que introduzcamos nuestra contraseña.

Si todavía no habíamos instalado el DNIe y esta es la primera vez que lo hacemos, puede pasar que en el paso final tras iniciar de nuevo la sesión en Mac y cuando se lanza automáticamente Firefox, nos diga que no se ha podido instalar el Módulo de seguridad. En ese caso a mi me ha bastado con cerrar Firefox, y al abrirlo de nuevo cargar otra vez el fichero de instalación file:///Library/OpenSC/share/web/instala_modulo_f3.htm y entonces sí que se ha instalado correctamente (tras confirmar los permisos requeridos)

Posibles problemas con los certificados

Otro posible problema con Firefox 4 (pero no exclusivo de Mac ni relacionado exclusivamente con el DNIe) es que al intentar acceder a alguna web con HTTPS nos muestre una ventana de error con este mensaje: "ssl_error_renegotiation_not_allowed"

Dicho problema está explicado por completo en el Wiki de Mozilla: Security:Renegotiation y básicamente se trata de que existe una vulnerabilidad en los protocolos SSL/TLS y desde Firefox 4 han decidido que lo mejor es bloquear dicha vulnerabilidad, e intentar conseguir que todo el mundo actualice sus servidores para evitar el problema.

Por tanto, lo primero que hay que hacer es enviar un correo al contacto de ese sitio web para indicarles la existencia del problema y que deberían solucionarlo lo antes posible. Cuantos más les escribamos, más posibilidades hay de que al fin se decidan a corregirlo aunque no sea más que para no tener que seguir oyéndonos.

Y mientras tanto, pues nosotros podemos hacer unos ajustes en nuestro navegador para poder usar esa web si así lo queremos:

1. Escribimos about:config en la barra de direcciones y pulsamos enter
2. Si nos avisa de que podemos estropear algo le decimos que sí, que estamos seguros de lo que queremos hacer.
3. Escribimos (o pegamos) security.ssl.renego_unrestricted_hosts en el filtro, nos aparecerá la preferencia correspondiente y por defecto como una cadena en blanco.
4. Le damos a editar y pegamos ahí el dominio donde nos ha dado el error (sin https:// ni las carpetas)
   

   

5. Si hay más de un dominio los separamos con comas.
6. A continuación filtramos esta otra preferencia security.ssl.treat_unsafe_negotiation_as_broken y la cambiamos a true.
   

   

De esta manera ya podremos acceder a ese dominio de forma temporal mientras corrigen los problemas con su servidor y lo dejan bien protegido.

Lo que NO es recomendable es cambiar la configuración de security.ssl.allow_unrestricted_renego_everywhere__temporarily_available_pref ya que eso anula por completo la seguridad y seremos vulverables en cualquier web al problema existente que estaban intentando evitar (es decir, por poder acceder a una web de esta forma se anula la seguridad en todas las webs)

 

Migrating from FCKeditor is a little easier now

There are tons of site out there that are still using FCKeditor despite the fact that it has been replaced by CKEditor and no work is being done to improve it since long ago.

There are several reasons about that, and one of them is the time cost of upgrading things like the configuration and now there's a little plugin that helps avoid at least one of those problems.

In FCKeditor the definition for Templates (HTML snippets) that the user could insert into the content was available in XML files, but as CKEditor was designed so it could be used in a cross-server environment that meant that the format was changed to JSON in order to load .js files from the server instead of trying to do a XHR that it's quite complex or impossible to do on a foreign server.

But the fact is that most of the people doesn't use CKEditor in such environments and also there are lots of people that have their templates specified in XML files and migrating them to JSON isn't obvious as no tool has been published to carry out that goal. Besides that, I personally find much easier to deal with XML files for the templates instead of the JSON version.

Example of a template in JSON:

   {
    title: 'Image and Title',
    image: 'template1.gif',
    description: 'One main image with a title and text that surround the image.',
    html:
     '<h3>' +
      '<img style="margin-right: 10px" height="100" width="100" align="left"/>' +
      'Type the title here'+
     '</h3>' +
     '<p>' +
      'Type the text here' +
     '</p>'
   },

The same template in XML:

 <Template title="Image and Title" image="template1.gif">
  <Description>One main image with a title and text that surround the image.</Description>
  <Html>
   <![CDATA[
    <img style="MARGIN-RIGHT: 10px" height="100" alt="" width="100" align="left"/>
    <h3>Type the title here</h3>
    Type the text here
   ]]>
  </Html>
 </Template>

In the JSON version you have to use single quotes on each line of the "html" and remember to concatenate everything. In the XML version you just paste whatever you want inside the CDATA comment.

Ok, that's fine. You might like one version or another, but if you want to easily use the XML templates in CKEditor, then upgrade to CKEditor 3.5.3 and add the XmlTemplates plugin.

 

New beta for WriteArea with CKEditor 3.5.3

Following the release this week of CKEditor 3.5.3, I've updated the WriteArea extension for Firefox to this latest version to include all the bug fixes and enhacements that have been worked on since the last release (check the change log, it's quite a long list as it's usual for every CKEditor release)

In this version, the only patch applied to the core is the latest from this ticket that allows a new button that you can use to switch toolbar on the fly.

The size of the extension has grown again a little due to several languages that have been updated since the previous checks that I did and so I've restored as new they can be correctly used to localize your CKEditor and not have part of the texts in your language and the other half in English.

Direct download link: WriteArea 1.1beta4

onChange event for CKEditor

It's a somewhat frequent request to see people asking how they can get a notification whenever the content of CKEditor changes.

Some of them are too optimistic:

I've this code <textarea onchange="myfunction()"></textarea> and when I use CKEditor "myfunction" is never called

But most of the people can understand the difference between the original textarea and a CKEditor instance and ask what's the better way to get a notification whenever the content changes, isn't there any built in event for that?

The answer is that no, there's no default event fired whenever something changes, but as I will show here it's quite easy to extend the CKEditor API and generate such event.

Generating a new 'change' event

Although there's no event for "the content has changed" there's something very similar, and that's the Undo system with its saveSnapshot event; whenever something changes it will be called, so we can listen for that event and it will help us greatly with our goal:

       editor.on( 'saveSnapshot', function(e) { somethingChanged(); });

That will take care if the change is something being changed like appying bold or any other style, a new table, pasting, ... it should handle almost everything. But there's one thing that doesn't file a 'saveSnapshot' event, and that's the undo system itself. When Undo or Redo are executed they don't fire that event, so we must listen to them:

        editor.getCommand('undo').on( 'afterUndo', function(e) { somethingChanged(); });
        editor.getCommand('redo').on( 'afterRedo', function(e) { somethingChanged(); });

Ok, Why "something changed"?
Answer: because we are not really sure that something has changed and we aren't really interested to know exactly what has changed, only that something might have changed. Any plugin will fire a "saveSnapshot" before and after any change to work properly, so in our function we will merge all those calls and fire a single event:

        var timer;
        // Avoid firing the event too often
        function somethingChanged()
        {
            if (timer)
                return;

            timer = setTimeout( function() {
                timer = 0;
                editor.fire( 'change' );
            }, editor.config.minimumChangeMilliseconds || 100);
        }

This way the editor will fire a "change" event at most every 100 milliseconds, and you can use editor.checkDirty() to verify if it has really changed (that call might be a little expensive if you are working with big documents, so it's better to avoid calling it too often by using something like the minimum 100 miliseconds that I've added)

Extra checks

To trap every change (and ASAP to avoid delays updating any UI that it's interested in this event I added also a listener for the afterCommandExec (I don't remember now which situation made me add it and I didn't put any comment explaining it :-(  )

        editor.on( 'afterCommandExec', function( event )
        {
            if ( event.data.command.canUndo !== false )
                somethingChanged();
        } );

and also a listener for the keyboard (don't know right now why I didn't listen for the editor.on('key') event; maybe I forgot about it) and new code to handle drag&drop (I've proposed to enhance the Undo system that way in ticket 7422 with some improved code)

        editor.on( 'contentDom', function()
             {
                 editor.document.on( 'keydown', function( event )
                     {
                         // Do not capture CTRL hotkeys.
                         if ( !event.data.$.ctrlKey && !event.data.$.metaKey )
                             somethingChanged();
                     });

                     // Firefox OK
                 editor.document.on( 'drop', function()
                     {
                         somethingChanged();
                     });
                     // IE OK
                 editor.document.getBody().on( 'drop', function()
                     {
                         somethingChanged();
                     });
             });

Ready to use plugin

Here you can download a zip with the full plugin and install instructions onChange event for CKEditor.
Obviously it can be improved, but the important part was to get something working good enough not to win a code contest about the best and most beautiful code.

Note: If you wanna link the plugin from any other site, please link this post so people can get the new versions when they are released instead of linking directly to the zip that will be outdated.

Edit: version 1.1 3rd September 2011

I've fixed an issue with the 'afterUndo' and 'afterRedo' events: they're fired on their respective commands, not on the editor itself; now the Undo and Redo buttons should work correctly. I can't understand how I missed that the first time.

Following the suggestion in the comments, I've added detection for changes in source mode, by keyboard, drag and drop and also on "input" if supported.

Edit: version 1.2 18th September 2011

The new CKEditor 3.6.2 fired the 'saveSnapshot' event too many times, just changing the focus might fire it and generate bogus change events when nothing has changed. Filtered those extra events.

The keyboard listener has been adjusted to ignore movement and other special keyboard events.

Edit: version 1.3 22th December 2011

Avoid firing the event after the editor has been destroyed.

Edit:

I've published a demo showing an usage example.

Edit: version 1.4 7th September 2012

Don't fire events if the editor is readonly, thanks to Ulrich Gabor.
Included code to use Mutation Observers (I'll try to explain it when I have some time).

Edit: version 1.5 20th October 2012

Detect Cut and Paste for IE in source mode thanks to Jacki.

Edit: version 1.6 18th November 2012

Detect multibyte characters thanks to Wouter.

Edit: version 1.7 6th December 2012

Compatibility with Source mode in CKEditor 4.

Note: 15th December 2012

Although the current version doesn't work correctly with CKEditor 4, I don't plan any future update.

Edit: version 1.8 8th June 2013

Use setInterval fix by Roman Minkin.

---

Notes to self about the Code highlighter plugin used in WriteArea:

• It doesn't remember the last used language reverting always to Java
• It doesn't prefill the content with the currently selected text

Creating extensions for each browser

These last days I've tried to create a similar extension for each browser, and this is a little recap of the first differences among them. A page with a full list of differences can be found in the State of the Add-on Developer Union

Firefox

In Firefox there are two options:

1. Create the extension using the "classic" way that goes back to the very beginning and provides full access to anything in Firefox, you can customize it in any way that you like.
2. Use the new Add-Ons SDK, only for Firefox 4. These ones doesn't require a restart and it's supposed to be future-proof.

In order to create a classic add-on you can get a skeleton using the Add-on Builder . There are lots of info about how to create these extensions and the API that they can use, and to start creating an Add-on the first step is this page to setup the environment. All you need is a text editor, some patience and be careful following the instructions. You can then configure Firefox to load the extension from the disk but when you make changes to the code you'll have to use an extension to force a reload of all the Firefox code or directly restart it; not nice.

To get started building add-ons with the new SDK, check the tutorial.
First problem: You are required to have Python installed.
What?
I'm so tired of projects that say: you have to install this or that or all of these projects just to get started.
What's so special about Python and the SDK environment that can't be done inside Firefox?
Why should I have to keep the list of instructions instead of being able to click on some buttons "Add extension", "Run tests", "Install", "Reload", etc...
Big boo here.
Maybe they want us to use wget instead of Firefox if they think that command line is so nice.

Anyway, I gave it a go in the Mac (I won't bother trying to install python in windows, it has already too many SDKs there for this and that), and so I followed the basic example, while trying at the same time to adjust it to my goal, I add the files, and when I do the "cfx run" then I get a cryptic error "raise ValueError('invalid resource hostname: %s' % name)". WTF? check again that I haven't done anything too weird. Nops. Then put back exactly the sample code. Nops. Search for the message. Bingo!, although there's no warning about this in the tutorial, you CAN'T use uppercase letters in the folder name. Hello Mozilla, it's 2011, I thought that the problems with uppercase and lowercase were gone long ago since MS-DOS. Why aren't your wonderful Python scripts able to deal with them?
Another big fail.

As a summary: I got a bad taste of the Add-ons SDK. When they put forward something that isn't oriented to Python lovers I might test it again (please note that I haven't even tested the API, just the environment makes me go back to keep using the classic method)

Chrome

It seems that there's a lot of work going on here in order to provide a very complete API for the extensions as well as good documentation and lots of examples. You can see a very basic one here and everything is quite easy to follow. Given the fast path that it's set on the release of new Chrome versions we can expect that this trend will continue and that they will add missing features to make some tasks even easier.

The only thing that you need is a text editor and Chrome, and by following the instructions you can get it working. It's not so powerful as the classic extensions in Firefox, but it's really easy to start creating an extension and there are lots of examples to check how they work.

Safari

It seems again that there's plenty of documentation at a central place, but just in the first page there's something strange:

Important: To develop extensions for Safari, you need to sign up for the Safari developer program online, at http://developer.apple.com. You need a signed certificate before your extension can be installed.

Uh?
So to create an sample extension in my own computer I need a certificate?

Ok, this shows again that Apple is a control freak. Why do I have to register to get an Apple ID and then get enrolled into a "Safari developer" program so that I can finally request a signing certificate, just to create a test extension? I can understand that in order to deploy it I might need to sign it, but I really should be able to create an extension for myself without the need to sign two looong agreements with Apple (I'm not sure if there was a paragraph about my first newborn there)

Anyway I go ahead and get a certificate in the Mac, and then it seems to work, but I would like to keep the development environment in Windows, so I try to install the downloaded *.cer there but anyway Safari keeps saying that there's no signing certificate installed. After a little while and some digging I realize that I must export the private signing key from the Mac KeyChain to Windows and once I installed it there Safari started working.

In some regards this might be the simpler interface of all the browsers in order to create an extension as you get a dialog to setup the basic configuration of the extension instead of editing them in a text file. The way that the code is setup is similar to Chrome (and Opera): background pages, injected scripts, so porting from Chrome wasn't a hard task.

As it happens with almost everything Apple does, if you are satisfied with what they offer, they try to make it quite easy, but if you want something extra then it's a no go.

Opera

I started checking the Opera API with the very first builds where they started adding support for extensions. In those days the API wasn't complete, there were a bunch of things that didn't work at all, so due to my hurry to test it I became a little frustrated because there were so many things missing, there was almost no documentation at the moment so it required a lot of effort to try to make something work because the examples were quite basic.

Now they have improved everything a lot, the behavior is similar to Chrome and Safari, but this is still a fresh SDK, so there are still missing features available in other browsers. They have written now lots of documentation and I guess that very shortly it should be quite easy to port an extension between Opera, Chrome and Safari due to the convergence of APIs that the developers find useful.

For the moment Opera it's lacking an API call similar to the ones that I've used for the other browsers so I will put the extension for browser at rest waiting for them to include them instead of struggle again and get tired of finding that it's not possible in any way.

Mobile test

A quick test of the new blogger application for android

Seems to support only plain text and pictures. Doesn't list existing posts or labels

WriteArea 1.0.1 Beta 1

Today I've uploaded a beta version of WriteArea to AMO, as I said, it has been updated to CKEditor 3.5.1 but besides that it includes (finally) a feature that it's the way that most of us expected the editor to behave: in-page editing.

This means that the editor is integrated into the page instead of a bottom pane or popup dialog. This feature is still experimental and there might be some unexpected problems, so please be careful (by saving drafts or copy&paste of the contents) before submitting the form.

This feature might have some improvements before the final release, but you can already start testing it

Some drawbacks (at least for the moment):

• It's not possible to revert the action, once the editor is created it only goes away when the page reloads (might not be a big problem)
• The clipboard operations are again restricted by default.
• The Open/Save draft features are no longer available. Maybe I'll adapt them to use HTML5 storage instead of saving to file.

Benefits:

• It's just easier to use and understand
• There can be multiple editors in the same page
• A button can be added so all the textareas are converted without using the context menu

Please, test it and tell me if you notice some problem or if you think that this is really the way to go and the other options should go away.

HTML5 Video plugin for CKEditor

You might have heard a lot of people talking about the new features of HTML5, and one that has brought a lot of interest is the <video> element that some people think that will avoid the use of Flash once and for all (at least Steve Jobs thinks so).

Personally I don't think that it will be so easy to dismiss a whole environment like Flash just because videos now can be played without external plugins, leaving aside the fight of h264 vs WebM (or as is now: Apple & MS vs the rest of the web), Flash has a lot of features that aren't easy to replace, the most basic one, the fact that you deploy a single swf file, vs having to provide several javascript and images just to perform anything basic with javascript. And as soon as you want to use some effects, you might end up with something huge and in fact as slow as the dreaded flash files.

But back to the topic, HTML5 video and CKEditor. What about that?

Ok, here we go, this is a plugin sponsored by DM Logic that makes using the <video> element as easy as an old <img>, you can insert, edit, use the context menu, etc... the dialog allows to specify the poster image, the dimensions (they are automatically adjusted according to the preview) and two source files, so that both the browsers that use the WebM format (Chrome, Firefox and Opera) and the ones that support only h264 (IE9 and Safari) can view your videos. Here's a short video showing how it works.

Download it here.

Updates:

v.1.3 26/08/12: Fixed problems with IE9, wrap the video in a <div> to avoid the problems with <p>. It's compatible with both CKEditor 3 and CKEditor 4

Demo

This is an editor. insert a video (I still haven't enabled the file browser for this demo)

 

 

Background image plugin for CKEditor

People enjoy colorful pages, background graphics and everything that can make their pages show their good taste, that's why some of them haver requested such feature for FCKeditor and CKEditor.

It's not clear if it might get directly supported in the core but here's a plugin for CKEditor to include a "Background image" field (with a button to launch the server browser) in the Table and Cell properties dialogs.

You can download the plugin here, the zip includes an install doc explaining how to use it, just extract the zip under the plugins folder for CKEditor and add "backgrounds" to the list of extra plugins.

Thank you to Igenti, Inc. for sponsoring the development of the plugin.

Avoiding extra request for the translation of a CKEditor plugin

When you write a plugin for CKEditor, it's almost for sure that it will include some text, it can be the tooltip for the toolbar button, a context menu entry or some change to one dialog, and you can leave that string hardcoded in your language, but it's usually better to use the localization features of CKEditor so it's easy for users in other countries to use your plugin, as well as allowing to easily change the text to fit better in a different environment.

As you might know this is achieved by setting a "lang" property in your plugin that it's an array with the list of language codes that your plugin provides:

 lang : [ 'en', 'es' ],

That entry tells CKEditor to load the file with the translation from the lang file of your plugin (lang/en.js or lang/es.js), and it's a pity that with all the current efforts about improving performance, due to the desire to provide the translation your editor might load slightly worse as it gets that extra file.

But there's an easy workaround, you can put the localization in the plugin.js file itself, so that when it checks what does it needs to load for this plugin, it can see that the translations are ready and so it skips for the next item.

Now each translation is just a line in the plugin and it doesn't require an extra request to the server:

CKEDITOR.plugins.setLang( 'backgrounds', 'en', { backgrounds : { label : 'Background image'} } );
CKEDITOR.plugins.setLang( 'backgrounds', 'es', { backgrounds : { label : 'Imagen de fondo'} } );

 

Security attack from IP 92.243.90.103

I've noticed recently that the IP 92.243.90.103 is testing several servers, requesting for files related to FCKeditor and then checking for the availability of the connectors to perform operations on the server (usually I think that it's more common requests related to tinymce filemanager, but it doesn't really matter too much).

I don't think that the requests are related to an unknown problem with the server connectors in FCKeditor as it seems to search both the asp and aspx versions (maybe it acts depending on the server software), but there are a few points that everybody should remember in order to avoid problems.

As every other time that I've written about this issues, let me remember you that I'm not a security expert and these are just some basic guidelines, the basis is that you should try to create an onion around the security of your server, different layers so that an attacker has to go through all of them, and hopefully he should be stopped at the very first steps.

Keep only the needed files

Whenever you use a third party software (or even your own software), don't upload to the server everything that comes in the shipped distribution. You won't need at the server source files, samples, documentation, or integration files for other server languages.

By removing those extra files you are avoiding a larger vulnerable surface and you can focus on the important files.

Security by obscurity can be useful

Yes, security by obscurity isn't really secure, but this kind of automated attacks that just search any number of domains for some files at specific locations like "/FCKeditor/editor/filemanager/connectors/aspx/connector.aspx?Command=GetFoldersAndFiles&Type=File&CurrentFolder=/" can be avoided if you place this 3rd party components in a non-standard location, so something as easy as putting the FCKeditor in another subfolder can avoid that an automated attack finds your files.

It's also important that the files that the users upload to your server with scripts like the FCKeditor server upload, don't end up in a folder that gives any hint about how they have been placed there, if your files are under /scripts/CKFinder/userfiles I'll know that you are using CKFinder somewhere in your server and more important, you are stating the path for CKFinder so you are weakening a little the security that you got in the first place by using /scripts/CKFinder instead of just /CKFinder

Expose the upload script only to users that can upload files

If a user doesn't have permissions to upload anything, then he shouldn't be able to see any hint about what are you using to manage the files in your server.

Secure the upload folder

The folder where the users are able to upload files shouldn't have permissions to execute any script, so even if they are able to upload a script, it won't do anything. Using the IIS control panel or .htaccess files in Apache it's easy to perform this task.

Keep your code updated

This can be a pain, but you once you start using a script at your server, you should check from that moment any new release about that project, paying special attention to warnings about security problems in new releases. I think that every project has some kind of RSS feed, so it shouldn't really be that hard to at least notice the new versions.

Enable file management wisely

In FCKeditor and CKFinder the server connectors include a config file where you can adjust some parameters (location of uploaded files, allowed or disallowed extensions, types of files, etc...) but the most important one is the ability to state if the script is enabled or disabled.

By default the server connectors are disabled in FCKeditor and CKFinder as that's the safe default, but people the complain that when they try to use them they get a message stating that the connector is disabled. Of course, that kind of people are showing that they didn't bother to read the minimum about how to configure these scripts, so they might end up using other ones that are enabled by default and they won't ever notice that now everyone can manage the files of their servers.

The correct step is to use the login credentials of your CMS to enable the file management only for the correct users, you don't really want an anonymous user being able to upload a file to your server.

Finally: be careful

As you can see, I'm not revealing anything extraordinary, these are just some basic rules that can provide some basic protection, but there are more that you should be aware of and that's part of the task of managing a web server.

When you pick a file manager for your server, don't think only about a few buck that you can save by using a free manager instead of a paid one, check how the security is implemented in each one, if an attacker is able to get control of your server you can lose many times that money trying to getting it back to normality.