If you know how to muck with about:config, there is an easy way to set your location manually.  First figure out your longitude and latitude.  There area bunch of tools on the web that gets you this.  Once you have this, you can do the following:

1) Open up about:config

2) search for geo.wifi.uri

3) change the value to:

http://snaptome.appspot.com/loc/json?latitude=your_lat&longitude=your_lon&accuracy=10

Thats it.  I hope this helps.

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

Play it here. You must be running Firefox 3.6 RC or better.

This uses the new orientation events added to Firefox 3.6.

Syd also put together a demo of what orientation looks like for those that do not have Firefox 3.6:

This web feature is going to be standardized in the W3C in one of two working groups.  The general idea is to separate out acceleration (values in g) and orientation (values in degrees for azimuth, roll, pitch).  More on that next year when we figure out where the work will be done!

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.

In this trivial example, the object |geolocation| is fully compatible with the W3C’s geolocation object that exists under the navigator object in web content. |successCallback| will be called when Firefox acquires your position.

The prompting of the user is left up to your application. All addons hosted on addons.mozilla.org must follow the guidelines and prompt the user.

If you have questions about what is permissible, please contact me.

=============================================================
how to apply a m-c committed patch to a release branch
=============================================================
hg qimport http://hg.mozilla.org/mozilla-central/raw-rev/
hg qpush
hg qref -e # add approval information
hg qfin .
hg push

What I did was basically the same thing, with a few shortcuts (insert your favorite story about how cutting corners can cause harm).

Basically I started out with a bug report. It has the information about what it fixed, who reviewed it, who approved it, etc. The first thing to do is verify that it all checks out and is a reasonable thing to do. In the bug, there usually a comment with the hg changeset information. Here was my first shortcut; I copied the url to the html version of the changeset from the bug, and run the qimport command. `hg qimport` has no problem with importing that patch (which should probably generate an error, but anywayz). What this did was imported a big html file — not what I wanted at all.

I then jumped over the `hg qref -e` command. This would have allowed me to see the changeset’s original comment. I would have been able to see that the qimport terribly failed. Also, this is a good idea to do so that you can add the appropriate a=foopy approval flag(s).

The last shortcut I took was I didn’t do a sanity check by running `hg out -p` which would have shown me what I was pushing. This is always a good idea to see what you are pushing. Sure reliance on the tools is fine and dandy, but actually seeing what hg thinks it is going to push doesn’t hurt and only takes a few seconds.

3 shortcuts resulted in a skidmark on the 191 push log:

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/739c7a69d412
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/1898753917d5

Sure there are worse things (e.g. patch bomb, pushing without testing, breaking trees), but I thought I would write this up both for clarification of how I messed up as well as a warning.

If you a linux laptop and have a few minutes, please download one of the Firefox Trunk nightly builds and try out orientation!

What to try?

http://people.mozilla.org/~dougt/ori.html

Let it run for a little bit, then shake your laptop (not responsible for any damage ).  After you have a couple dozen responses, send me the results including what distro and laptop you are using.

Demos!

While you are testing things out, check out the demo Michael Ventnor (m.ventnor at gmail.com) put together:

http://dougt.org/random/orientationdemo/index.xhtml

Justin Dolske has a few demos too:

• Seismometer
• No idea, but it’s awesome

Jesse Ruderman also cleaned up the “ball” demo that I created making the animation smoother.

Help Wanted

There are still other platforms that I would like to support.  I specifically would like to see Windows support using their Sensor API.  If you are interested in helping, file a bug, cc me, and take a look at the other implementations.

Obviously clear that there should be a webapp for doing just that.  What was missing was a javascript API.

In recent Mozilla trunk builds, I have added support for an orientation event.  This new event will allow you to build applications and listen for changes in orientation.  (note, the first platform to support such an event is any MacBook Pro.  Others will follow).

Simple Call:

To use this new event, you will add an event listener as you normally would:

window.addEventListener(“MozOrientation”, orientationChange, true);

Your callback will be called, when there is a change in acceleration, passing the current orientation:

function orientationChange(o) {

}

Simple Result:

The passed object has 3 attributes – “x”, “y” and “z”.  Each value is between -1 and 1 where zero is the “balance point”.  For example, suppose you device is a MacBook Pro and it is sitting on a desk that is perfectly level, you would expect to see:

x = 0
y = 0
z = 1

x is the axis in the direction from the left side of the keyboard to the right side of the keyboard (basically the axis that is along the home row keys) is level.  If I lift up the left side of the keyboard, x will increase.  if I lift up the right side, x will decrease.

y is the axis in the direction from the front of the laptop (where the mouse is) to the back of the laptop.  If I lift up the front of the laptop (the side closest to me), y will decrease.  If I left the back towards the front, y will increase.

Got that?  Yeah, physics is pretty hard.

x and y can easily be visualized.  If you have a recent trunk build for the Mac, try loading this demo page:

http://people.mozilla.org/~dougt/ball.html

z basically will tell you that the laptop is sitting right side up.  if z was -1, you would know that the laptop (probably closed) and is sitting on its screen.  Of course the value will change as you rotate the laptop / device in this direction.

Right now, there is only support for the Macbook Pro.  It is pretty easy to add support for different OSs.  We have code for Samsung Windows Mobile devices, and for the HTC Windows Mobile devices.  We still need support for linux and for Windows.  If you are interested in adding support file a bug and start looking at http://mxr.mozilla.org/mozilla-central/source/widget/public/nsIAccelerometer.idl

The API isn’t fixed and may change.  I do invite you to comment.  Keep in mind that we want a really simple and straight forward API to expose orientation events to web developers.  If your response has either “RDF” or “DCCI” in it, please reread the last sentence. 

Thanks again and hope you enjoy.

For example, instead only being able to work with:

37.3882005, -122.0834553

You can see the physical address as:

650 Castro St, Mountain View, California, 94041, US

This should help aide the many people that already know their physical address in familiar terms.

To access address elements, you simply do what you have been doing.  The only modification is to test to see if there is an address associated with the position, and if so, access it:

navigator.geolocation.watchPosition(successCallback)
function successCallback(position)
{
    if (position.address)
        alert(position.address.postalCode);
}

Other fields on the address object are:

address.streetNumber
address.street
address.premises
address.city
address.region
address.county
address.countryCode
address.postalCode

Please let me know what you think.

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.