Desktop Notifications

Desktop notifications allow a web page to notify the user using system level services, such as Growl, in a clean, safe, and easy to use manner.

The code is very simple:

navigator.notification.notify("Another Desktop Notification",
                              "Check out my icon",
                              "http://dougt.org/me.jpg");

and the result is something you’d expect from a notification.  On the Mac, the notification may look like:

You can get more sophisticated by adding a callback when the user clicks on the Desktop Notification:

navigator.notification.notify("Another Desktop Notification",
                              "Check out my icon",
                              "http://dougt.org/me.jpg");
                              function() { /*do something*/ });

A user must grant each site permission before they can use Desktop Notifications.  We will use the familiar notification bar (the text isn’t final.  Also, these will end up looking quite different in future releases of Firefox.):

That is there all there is to it!

Get involved:

If you like or dislike this feature, please just leave a comment.

If you like to follow the implementation details, you can follow bug 573588.

You can try out the engineering builds.  There are bound to be a few bugz.  If you see anything funky, please let me know.

If you are using the above engineering builds, you can try out Desktop Notifications.

More details:

I reviewed two draft specifications.  The first is the WebNotification specification and the other is the Google Gears NotificationAPI.  I found both of these APIs more complex than what was required.  Clearly both of these other APIs have use cases that are not address by my proposal.  But for basic notification from the browser, not much is required.

Looking at what Growl and other system level notification services provide, you basically only need a title, a description, and an icon.  For fun, I added one callback if the user clicks on the notification while it is on screen.

Next Steps

You tell me.  Is this something you’d like to see in the browser?  Does the API work for your use cases?

Let me know what you think!

http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/latest-mobile-trunk/fennec.apk

No auto-updating yet, so check back often.  Send your feedback to the forum.

There are lots of nobs and switches to gource.  The command to produce this video is:

gource -s 0.001 –output-framerate 25 –highlight-all-users –stop-at-end –disable-progress –auto-skip-seconds 0.1 –file-idle-time 10 –max-files 1500 –multi-sampling -1280×720 –stop-at-end   –output-ppm-stream – | ffmpeg -y -b 30000K -r 60 -f image2pipe -vcodec ppm -i – -vcodec libx264 -vpre hq -crf 28 -threads 0 fennec.mp4

Our situation in Fennec is that we have a hidden browser element that contains the flash object/embed element. When a paint needs to happen, we draw whatever the plugin wants to draw into a canvas or sent of canvas elements. These canvas elements are what the user sees on the screen — they are part of Fennec’s tile manager. Now these draws to the tile manager consistent of a 16bpp to 24bpp conversion (I am told that the flash is optimized for 16bpp), then a copy to a gfxXLibSurface, then a final blit to the screen. This final bit also contains a 24bpp->16bpp conversion because the screen is 16bpp. To make matters much worse, many plugins intersect multiple canvases in the tile manager which causes this drawing path to happen multiple times per video frame. The end result is that we were getting no more than 4-5 fps.

We took some incremental steps to improvement performance, but we were no where close to double digit fps.

At this point, we decided to just draw directly to the screen avoiding the tile manager completely. This allowed us to render without any conversions and only one copy — the plugin could write directly to X11 shared memory.

In making this decision, we would lose a bunch of information that Gecko provides such as where the plugin should be position relative to other elements, and how it should be clipped.  The solution we came up with was to let Fennec tell each of the object and embed elements where they should be drawn.  The frame painting code would honor the position and clip that the front end set.  In this way, we could have plugins do the right thing during pans and when content is below the Fennec sidebars/urlbar.

You can check out how Fennec positions elements here:

http://mxr.mozilla.org/mobile-browser/source/chrome/content/browser.js#2937

The end result in this work is that we get over 25fps when Sorenson encoded videos.  Over the next weeks and months, I hope to see more video content honoring Fennec’s user agent and provide optimized content.  (YouTube and other sites do not recognized Fennec’s UA, yet).

This fast path is only implemented on Maemo, but it can be implemented on any platform assuming the plugin has support to draw directly into a memory buffer.

You also can check out the details in bug 528551.

This idea isn’t new. We have been researching meshing geolocation data and the web for a few years. Last year, Mozilla Labs released an experimental addon, Geode, which implemented the draft W3C Geolocation Specification. We added support for the spec to Firefox 3.5 and “Fennec” (our mobile browser which is in development) as well as a user interface that put the user in control of which websites could use location. However, we left it to add-ons to implement the code that would actually figure out your location, using any technique (GPS, WiFi or cell tower triangulation, manual address entry) of their choosing. So, with Firefox 3.1, 3.5 or Fennec, plus a third-party add-on, users would be able to use location-enabled websites.

However, we were still left with a chicken-or-egg problem: unless lots and lots of users installed an add-on, websites wouldn’t have a significant audience for which to develop location-enabled services; and without lots of useful web content using the feature, users had no reason to install an add-on.

We decided to investigate bundling a technology that would provide an end-to-end solution, so that the feature would work out of the box for users, and would give websites a large enough potential user base to kick start the development of innovative apps and services. We had learned a lot from the discussions about the various add-ons that had been built, and in other forums over the last few years. Earlier this year, I hosted a talk on Location in Mozilla during which we reviewed many of the critical privacy issues. We boiled these down to some key principles:
* protecting user privacy.

User privacy is super important to us and we believe that we have the best privacy policies regarding your data. The use of the WiFi data, IP addresses, associated protocol bits, should never be used to spy on users, track individuals, or shared without your permission.

* enabling web developers to use the API in an unencumbered way that would work in all browsers that implement the spec

Web developers can use a standard way of accessing geolocation data and not have to worry about the underlying geolocation provider. We don’t share with third-party location provider(s) any information about websites the user’s visiting; this protects both the user’s privacy, and the website’s right to write to a web standard without fear of any third party gaining insight into how the site is being used.

* preserving user choice

This feature is completely opt-in! If you don’t do anything, geolocation is never used. When a web page wants ask you for your location, you get an dialog similar to the one below. If you do nothing, the feature stays off by default. Only if you press “Tell them”, will you send out your location information. Furthermore, users are free to use a different geolocation provider by installing addons.

* applicability to both Firefox and Fennec

To avoid fragmentation on the web, the geolocation feature should be consistent between the desktop and mobile. The truth really is that the line is getting blurred between mobile and desktop. Calling the geolocation feature “mobile only” discounts many use cases that are pretty important.

Given these principles and a strong desire to create an “out of the box” experience in Firefox and Fennec, and to kick start the location aware web, we are happy to announce that Firefox 3.5 and Fennec will be using Google Location Service. We found that we agreed on the many privacy concerns around location. Do check out Mozilla’s privacy policy and Google’s privacy policy. I am pretty excited about these policies I think they are going to be the industry standard when it comes to network based geolocation providers.

Just to provide a bit of technical detail on what exactly is going on, below I will walk through a simple geolocation request.

1) A user goes to a page that has some Javascript that asks for a Geolocation.

2) When the user loads that page, we put up a dialog.

3) If they don’t click anything, or click no, we do not do any geolocation stuff and simply return an error to the requestor.

4) If they click yes, we drop into this bit of code which packages up the WiFi Access Point data into JSON and sends it to Google Location Services over HTTPS. The URL is configurable by preferences (“geo.wifi.uri”). The data sent includes a version number, access token, and an array of public WiFi access points data. The access token basically acts like a two week cookie, and if you clear cookies in the browser, this value is deleted and a new one is used.

6) Lastly, the Google Location service returns a location. It’s another json object that is an actual location.

That’s it. For more information, check out the Frequently Asked Questions. Get ready for Firefox 3.5 and start thinking about how you can location aware your web apps! Here is the spec.

Got questions, feel free to ask. I am looking for feedback. Comments welcome.

In 2004 we had a project called Minimo — it was meant as a lighter weight build-time configuration of Mozilla for GTK. To showcase the build options, we had an application called TestGtkEmbed that developers could use to test against benchmarks, etc. As the name implies, it was just a testing application — it didn’t have browser features like bookmarks, session history, preference management, etc.

At the end of 2004, I was hired by the Mozilla Foundation working for Chris Hofmann, who was the director of engineering. I started on porting this set of build options to Windows Mobile. At this point, there was no real desire to build an application — I was happy to just continue building a browser engine that could be part of another application.

I really had no desire to do Windows Mobile development. However, at the time, it was really the only devices available that people could by off the street and run very large applications on (think: a modern web browser). The idea was that you could do direct-to-consumer development.

We found that there was some work done by Garrett Blythe (i don’t have a better link, sorry) at Netscape in 2002 which we could leverage — there was a partial patch to NSPR for windows mobile. Garrett was responsible for an effort to port Netscape to Windows CE. His basic approach to porting from Win32 -> WinCE is is what I continued using (and we still use most of it today).

At the beginning of 2005, Brad Lassey started helping and around March 2005 we had much of the platform ported over. Below is the picture of the first time mozilla rendered google windows mobile phone:

If you want to see other pictures, check out rebron’s posts from way back when.

At some point, we needed to branch away from using WinEmbed (basically the same thing as TestGtkEmbed i mentioned above, but for windows) and decided it was a good idea to build a UI for Minimo on Windows Mobile that end users could use. Looking at something we might be able to share between the linux/gtk version of Minimo and Window Mobile, we decided to write the UI in XUL. The size/space measurement for using XUL were very small compared to the flexibility you got (we were thinking extensions).

Working from Brazil, Marcio Galli was basically responsible for the front end. We experimented with a bunch of things like social bookmarking, geolocation, device API, and widgets. We learned alot, and some of this ended up being the basis for a draft spec.

In April 2006, I stopped working on Minimo full time and started other mobile work for Mozilla. The Minimo project continued. I tried to work fix the occasional bug, but development basically ended.

At the end of 2007, I blogged about the end of Minimo (the windows mobile mozilla browser) and a new effort called Fennec. Our team now is much larger than the original effort; we have people in QA, Press, IT, UX, Marketing all thinking about Mobile.

Now, we have our first public milestone release. A completely new font backend, cairo support, extension support, and basically everything that Firefox has.

Today is the rebirth of this browser: Better, stronger, faster. We have a way to go before we declare a “1.0″ release, but hope you come with us and participate in open source, mozilla, and Fennec – our mobile browser.

Today we are releasing a pre-alpha version of Fennec for Windows Mobile. This release is pre-alpha. Did I say pre-alpha? Yes, this is pre-alpha and has a way to go in both stability and performance before we release this as “1.0″.

Please try out and give us feedback! Please file bugs at bugzilla.mozilla.org.

Download link:
http://ftp.mozilla.org/pub/mozilla.org/mobile/fennec-0.11.en-US.wince-arm.cab

Brad has instructions here and a great overview:

http://blog.mozilla.com/blassey/2009/02/10/fennec-milestone-release-for-windows-mobile/

Developers:

Get involved. If you are a windows mobile hacker, we would love your help making Fennec better. Find us on irc.mozilla.org #wince.