Since the start of 2010, Firefox and Internet Explorer were more or less head to head in Greece at about 44% each.

Since the start of March 2010, Firefox increased the gains compared to Internet Explorer.

The peak half-way in the graph corresponds to the Greek Orthodox Easter vacation period.

The graph depicts the weekly browser statistics in Greece from February 2010 up to the end of May 2010.

The daily statistics have a peculiar pattern. During weekends, the usage stats for Firefox are shot up while Internet Explorer shows a significant dip.

However, during the weekdays the stats for the two main browsers are balanced out. This pattern (which is replicated in most European countries), shows that a significant number of people at work are forced to use Internet Explorer. It is easy to identify country-wide strikes through the disruptions in this pattern.

The graph depicts the daily browser statistics in Greece for May 2010.

Firefox increased the market share to almost 2% since the start of 2010.

At the same time, Internet Explorer lost close to 5% of market share.

Apart from Firefox, Chrome was a big benefactor of market share, increasing to almost 9%.

The graph depicts the monthly browser statistics for Greece, for the first five months of 2010.

The Greek localisation of Mozilla Firefox is maintained by Kostas Papadimas.

What is the case with other countries? Did BrowserChoice have an effect to other European countries?

Related posts:

1. Firefox 3 statistics, and the Greek language Firefox 3 was released on the 17th June, 2008 and...
2. Firefox και Ελλάδα Τα πιο πρόσφατα στατιστικά χρήσης λογισμικού περιήγησης ιστοσελίδων (web...
3. ΝΑΙ! Mozilla Firefox No1 στην Ελλάδα! Μιλήσαμε πρόσφατα για τα στατιστικά χρήσης του Firefox στην Ελλάδα....

Mozilla along with Mahiti organised a Mozilla Developer Day at NIMS, Bangalore at JRD Tata Auditorium. For people who want to know about the event via tweets please check the hashtag #mozdevday on Twitter

Introduction

As per the schedule, the event was supposed to kick-start at 9:30AM in the morning. After getting up in the morning and beating all the traffic as travelling 33KMs, I finally reached NIAS Campus at 11AM. After getting the badges, feedback-form and other delegate stuff, I went inside the auditorium to see what’s cooking inside.

Web Standards

Speaker: Arun Ranganathan

When I entered Arun was speaking on Web Standards. I think I missed the drum-beat part of his presentation as I was late. Abhishek Mishra and Rohan Prabhu had reached at 10AM itself and were a part of the audience from the very beginning.

Arun gave us a presentation on

• Geolocation based services for pictures.
• Font-face support in Firefox and other HTML5 based controls.
• API for drag-and-drop
• 2D support in Firefox. He showed us a Mario kind of game made using Canvas.
• 3D support in Firefox using WebGL
• Accelerometer support for Firefox. He showed a game which we can play by tilting our devices (Mobile/Laptop)
• Video support in Firefox using HTML5

Arun even showed us how powerful video tag is on Firefox. We can embed a text inside a video, or even a video inside a video. Don’t believe? Have a look at the page where Arun pointed us to visit

Web.Next

Speaker: Seth Bindernagel

Seth is the localisation Director at Mozilla. He was speaking on what we can expect next from Firefox. His presentation covered mainly:

• Out of Process Plugins
• Improved cold startup time
• Personas
• Extension Manager
• Weave

Seth discussed a bit on how Flash crashed are a big headache for the web. The next Firefox will have these plugins running as separate processes, so that the crash effects can be isolated.

For people who actually want to see how Flash crashes on the browser and how easy it is to make Flash go bonkers, just visit this site http://flashcrash.dempsky.org/

Seth also gave a lot of time on Weave and how useful it can be for a person to sync his preferences on the cloud. For privacy fanatics, he explicitly stated that all the data is encrypted at client side and then sent on the Mozilla servers. People can even run their own Weave servers.

Mozilla Labs

Speaker: Ragavan Srinivasan

Ragavan came on the stage to  present Mozilla Labs and what all they develop apart from the browser. The products which come out of the lab are Weave, Bespin and Jetpack.

Broken Sites

Speaker: Arun Ranganathan

If you visit MS Ramiah Institute of Technology’s Student Information System or FYJC’s site using a non-IE browser, then you can experience the over-smartness of the super intellectual web-masters behind the site. FYJC takes the situation to extreme levels.

Arun explained how we are supposed to report these broken sites using Firefox itself or using Mozilla Bugzilla. When using bugzilla, the explanation needed to be very exhaustive. He even asked us to tag such reports with “India” so that Arun can personally hunt down such sites.

Hack Session

Speaker: Arun Ranganathan

Arun recorded a video using a camera. Then he transferred it to his MacBook which was in MP4 format. He created a small page using HTML5 video element and opened it in Firefox,Safari and Chrome. The video which was recorded showed up properly in Chrome and Safari and not in Firefox. This was posed as a question. Many hands went up, with the first answer being the correct one. Yes. Firefox wants the web to be free and doesn’t want to license proprietary codecs for the web.

The million dollar question remains – How to convert H.264 videos to open format. Arun introduced us to a Firefox Addon named Firefogg. This converts the video to ogg which can be now played using Firefox and Chrome. Safari doesn’t want to support ogg.

I know I made no reference to Mahiti’s speech and Praneesh’s too. The post would be just too long.

Finally I would like to thank Mahiti and CIS-India for organising the event, providing free WiFi and arranging Lunch, tea and T-shirts and badges.

Disclaimer: If you are reading this via PlanetPlanet or a non-javascript aggregator, please visit the real page to read more

You know, we are living in a world of SOA. And even if we don’t like the new world order of the web, sometimes it can make our lifes easier.

We think that, right?

Right now I’m working on the re-implementation on my DjangoFAIed project. Which means, I’m in need of a separation between shiny new bling bling named web frontend and boring looking jsonrpc or xmlrpc for the web backend.

As you know, I’m working with Django for the daily system development, so here I’m in love with Django and RPC4Django.

The good thing about RPC4Django is that it gives me an easy way to provide two RPC types but only writing one backend.

So, having this in place, and doing some xmlrpc calls from the FAI side of life, I just need to find a way to deal with the web frontend.

So, here we are, my high rated topic: XMLHttpRequests, Javascript and Browsers, and what are they supporting.

There are at least 4 browsers I would care about:

1. Firefox >= 3.5
2. Google Chrome
3. IE8
4. Safari

No. 1 is my choice when developing some bling bling, No. 2 comes to my mind if I want to have a fast Javascript Execution time, No. 3 and No. 4, oh well, I use FF and Chrome even on windows, and I never had to do anything with Apple ;)

Creating our testbed

Now, let’s setup a testbed for the application. Let’s assume:

1. http://testrpc/ -> this is the domain where Django lives. It’s setup and runs like a charm
2. http://testhtml/ -> this is where our test web application is living. It consits right now of one web page, named index.html
3. For doing some simple javascript work we are using jQuery delivered by the google cdn
4. Our webserver is Apache 2.2.x
5. We are using WSGI as gateway to our application (mod_wsgi)

Now, I hope you have a django installation (I’m already using 1.2 beta) and installed RPC4Django. Create a new django application and add to the __init__.py file these methods:

This is how we define a new xmlrpc/jsonrpc call which just returns “Hello World”.

Now add to your djangoproject urls.py this endpoint for our RPC calls:

(r'^RPC2/$', 'rpc4django.views.serve_rpc_request')

and add your new application and the rpc4django application to your settings.INSTALLED_APPS.

Setup your apache installation to serve your application, don’t forget your wsgi_handler.py.

Now, if we start a browser and enter “http://testrpc/RPC2/” into the location bar, you will get something like this:

(Picture taken from: David Fischer RPC4Django)

To test if our application is working just create this little xmlrpc client app:

It should print out “Hello World”.

Creating the web frontend

As said before, we are using jQuery as DOM library to make our lifes easier, regarding Events and Ajax things.

Let’s see how this goes:

This page includes the jQuery Script from the Google API CDN, you need to get the json2.js from http://www.json.org/
and put it in your documentroot or in your directory where the html file is saved.
When you point your browser now to this page, and you click with your mouse on “click here”, the javascript fires an click event, and inside this click event, it starts to make a Ajax Request against our rpc django app.
The result of this ajax request should be, that the content of the “<DIV> with the ID of “#testOutput will change its content and displays “Hello World”.

“Oh, but you can’t do XMLHttpRequests across different domains! It will fail, and you should know about the same origin policy !” you will say now, and you are right.
But, thanks to the “Web Applications Working Group” we have something new: CORS or simply named: Cross Origin Resource Sharing.

Cross Origin Resource Sharing – CORS

What is “CORS”? you will ask now. The working draft abstracts it like this:

This document defines a mechanism to enable client-side cross-origin requests. Specifications that want to enable cross-origin requests in an API they define can use the algorithms defined by this specification. If such an API is used on http://example.org resources, a resource on http://hello-world.example can opt in using the mechanism described by this specification (e.g., specifying Access-Control-Allow-Origin: http://example.org as response header), which would allow that resource to be fetched cross-origin from http://example.org.

(from: Cross-Origin Resource Sharing, W3C Working Draft 17 March 2009

This really sounds important, right? What it just says is, that now it’s possible to make Cross Site XMLHttpRequests under special cicumstancas.
What we just need to know is that Mozilla implemented this feature already in all Firefox Browsers >= 3.5.
Mozilla calls it “HTTP access control“.

Now, you will bring this example to work when you enable mod_header of your apache installation and add to your test virtualhost something like this:

Pay a bit of attention to the “Header” line. What it will do is easy: It will spit out a new Access-Control-Allow-Origin Header, which is set for anybody to make cross site XHR requests to your site.
It’s just like a bit when you tell Adobe Flash Crossdomain.xml to ‘allow-from-domain “*”‘. Different names, same result.

Now, restart your apache server and try the demo page again, now it should work like a charm. The contents of the div will change to “Hello World” and we are done.

Are we really done?

Oh well, not quite done. Now we need to test this positive result in another browser, let’s choose Google Chrome.

To make a long story short, somehow this example doesn’t work, but regarding all the postings on the fantastic lazyweb, Google Chrome does support CORS!
Well, not really. It does support this feature under special circumstancas. This document tells us more.

Regular web pages can use the XMLHttpRequest object to send and receive data from remote servers,
but they’re limited by the same origin policy.
Extensions aren’t so limited. An extension can talk to remote servers outside of its origin, as
long as it first requests cross-origin permissions.

(taken from: Google Chrome Extentions: Cross-Origin XMLHttpRequest)

There is another explanation.

Content scripts are JavaScript files that run in the context of web pages. By using the standard Document Object Model (DOM), they can read details of the web pages the browser visits, or make changes to them.
Here are some examples of what content scripts can do:

• Find unlinked URLs in web pages and convert them into hyperlinks
• Increase the font size to make text more legible
• Find and process microformat data in the DOM

However, content scripts have some limitations. They cannot:

• Use chrome.* APIs (except for parts of chrome.extension)
• Use variables or functions defined by their extension’s pages
• Use variables or functions defined by web pages or by other content scripts
• Make cross-site XMLHttpRequests

(taken from: Google Chrome Extentions: Content Scripts)

Now what?

Now we have a good, fast and cool browser named Chrome, and it does not work as expected.
It should support this out of the box, and it should work like Mozillas implementation.
There are discussions in the background, regarding Greasemonkey and CORS.

Honestly, I’m writing “intranet” applications, I don’t want to use CORS in external applications. But regarding the CORS specification, I do like the way how this goes.
No need anymore to do cross site XHR via iframe (which works, but is actually painful). Furthermore, it can be a nice standard.
What we need to avoid is that really good browsers like Mozilla FF and Googles Chrome are doing what we always hated about MS: Going two different ways.

I also don’t want to write two or three different JS implementation to do the one thing. I really don’t want to support more then one browsers javascript implementation.
So, how can I get this to work without doing the old painful “iframe” way, and without writing a google extention?

Recently Apple launched the Ipad (could you possibly have missed this?) and now rumors says that Google is working on a tablet PC too. On the Google site The Chromium Projects you can see visual explorations of how a Chrome OS tablet UI might look on actual hardware. The site has a strip of photos of the concept which is a lot similar to an Ipad.

Google's Tablet PC will naturally run its own operating system, Chrome, which implies that the web browser is in focus, and that all applications available from the web. The video below demonstrates how Google envisions that this new gadget will work.