When I was a part of Mozilla Labs day to day, I always loved the vision and team behind Weave. I kept wanting the implementation to match the vision, but it is a tough problem and it takes time to bake. Well, it is getting there now.
Weave is special because it offers a series of back-end services (more than just sync) that are build with users (and their privacy) in mind, rather than business models. I have talked to a couple of entrepreneurs recently and thought that there ideas could be implemented nicely on top of Weave.
It is still early days, but I am jazzed to see the platform getting opened up. I am hoping to get clients for Safari, Chrome, and IE…. and look forward to a webOS client too :)
Sometimes you need to compromise, but at others you need to lead and take a stance. Our politicians do far too much via polls, and I often find myself wishing for more leadership. I could start talking about Obama and the healthcare issue in the US….. but this is a technical blog so I won’t put you through that.
With Chrome and Safari supporting H.264 (and not open video formats such as Ogg Theora) some users and developers have asked for Mozilla to support it too in Firefox. Mozilla is certainly a user-centric group (which is how they have gotten so far with Firefox) but remember that they are mission based: to keep the Internet open.
Here is some of RoCs opinion. I am glad he shared it:
Taking such positions is nothing new for Mozilla and history has proved us right for doing so, in particular regarding ActiveX and Web standards in general.
Perhaps it’s not widely known, but Gecko has had code to support hosting ActiveX controls, dating back as far as 1999. ActiveX controls are very much like system video codecs. ActiveX support would have been very useful to users ever since 1999, and still would be now — certainly in corporate intranets, and everywhere in China and South Korea. Enabling ActiveX support would probably boost our market share significantly. Most users have useful ActiveX controls on their machines. But for the last ten years, even during Mozilla’s most desperate days, we have consistently refused to turn this feature on, because we believe that ActiveX is not good for the Web.
I’m not suggesting that the consequences of exposing system codecs to the Web would be identical to exposing ActiveX. That’s unlikely, and unknowable. But favouring our principles over short-term gains for users is nothing new for Mozilla, and when we’ve done it in the past, history shows it was the right thing to do.
Mozilla has said it will “probably” open a marketplace for Firefox add-ons sometime next year.
Add-ons product manager Justin Scott (reluctantly) announced the news this morning at an add-on-happy conference in Mozilla’s home town of Mountain View, California. “We’ll probably be doing a marketplace pilot in 2010,” he said.
Scott did not provide details. But earlier in the morning, he did say that Mozilla has no intention of using DRM – not that you would have expected anything else. “I don’t know what we’ll do, but we won’t do DRM,” he said.
It wouldn’t be too surprising to see Moz bolt in a payment model to the existing add-on repo, which already has a review process. Of course, once you start paying developers to build add-ons, many more add-ons will need to be reviewed and Mozilla will have to make tough decisions about to what extent add-ons will be reviewed, if at all, and what kind of charge, if any, will be imposed on add-on providers.
There are already some browser extensions that come with a price tag. This happens in both IE and Safari, both browsers lacking a vibrant extension community; and it also happens with Firefox, where there is a vibrant community of typically free, open-source, extensions.
An add-on marketplace would formalize the payment model and add a big incentive for developers to build seriously useful add-ons, given the possibility of reaching a market in the hundreds of millions. The flipside is that we might no longer see free versions of some of our favorite add-ons. Given its open-source DNA, it might be nice to see a “donate” button beside any of the free offerings in the store. (Update: Ryan Doherty points out in the comments there’s already an add-ons contibution feature, pilot launched in July.)
It’s also interesting to consider how an app store might open up a marketplace for new types of add-ons. For example, if you see the browser as a convenient sandbox to drop small desktop apps into, we could end up with simple games and utilities which might otherwise be released as shareware. Print-on-demand might be another application.
This is all hypothetical for now, but it’s still fun to speculate on what could become of AMO!
Improved JavaScript performance, overall browser responsiveness and startup time.
Support for new CSS, DOM and HTML5 web technologies.
But there is so much more. There is a ton of CSS work including background-size, gradients, and multiple background images. Video can now have a poster frame, HTTP activity can be monitored, Web Workers can self-terminate with close(), drag and drop supports files via DataTransfer, window.onhashchange.
As well as the nice new look, there is a new API with nice methods such as getObjectTable that includes a lot of great work such as looking at the shape of objects and deep understanding of the platform to let the real information rise to the top.
Firefox 3.6 alpha releases have already arrived and there are already cool new features on the heals of the 3.5 release, as well as rapid speed improvements.
DOM changes to elements using the table display types now work much better.
You can determine whether or not content is being rendered on a touch-enabled device using the new :-moz-system-metric(touch-enabled) selector.
The reorder event is now sent to embedded frames and iframes when their document is loaded. See bug 420845.
The getBoxObjectFor() method has been removed, as it was non-standard and exposed even more non-standard stuff to the web. See bug 340571. Also affects mootools which uses this call for Gecko detection. See this mootools bug.
A new attribute has been created, mozScreenPixelsPerCSSPixel, for obtaining the amount of screen pixels per CSS pixel on nsIDOMWindowUtils. This can be used in conjunction with the new global properties, mozInnerScreenX and mozInnerScreenY, to compute screen coordinates. See
When the page's URI's document fragment identifier (the part after the "#" (hash) character) changes, a new hashchange event is sent to the page. See window.onhashchange for more information.
Geolocation "address" support is now available enabling user-readable position information. See
The Jetpack project is still a young 'un from Mozilla Labs (disclaimer: I work for labs!) but they are moving swiftly indeed, and each new release has a wicked cool new API that let's you do something you couldn't easily do before.
Play the local file back with jetpack.audio.playFile() or upload it and just use the audio tag itself.
A great showcase of this is the voice memo jetpack "which lets you annotate any webpage you are looking at with your voice." Live streaming is even coming soon. Here comes video conferencing the Open Web way?
Jetpack is a great way to do Greasemonkey-like work. To make it even easier, you need a way to define when the jetpack kicks in etc, and this is exactly what the Page Mods API gives you.
With the Tools Directory, we hope to provide a central location where the community can track what's happening in the tools space. At Mozilla, we release early and often in the open-source tradition, so what we've launched is the first step in the journey. We'd love to get your feedback in this early stage as we evolve the directory.
We've got nearly 70 tools in the database so far, but that's just a small fraction of the hundreds of tools out there. Would you help us out and tell us about your favorite tool(s)? (We're still working out infrastructure, but eventually we'll have a way to own a tool and keep its metadata up-to-date. And our sincere thanks to Laura Thomson who worked very hard to help us get the infrastructure and back-end for the directory ready.)
Dion and I both have some corporate IT experience under the belt, and because of that we just couldn't bring ourselves to write yet another typical table-based database CRUD app; hence, the space theme and gratuitous canvas-based UI. So the Tools Directory is our second canvas-centric web application released this year, but we promise to use the DOM API more for the next one. ;-)
Implementation Details
We knew we wanted to do some kind of space-themed design for the directory involving images for the tools flying around, but we weren't sure how much performance we could get out of canvas. Some of our previous experiments have shown that we can repaint a large canvas many times per second, but how many individual images could we paint per frame full-screen and still get decent perf? This experiment, representative of several we whipped up, was somewhat promising: we're able to draw and scale about 700 images about 20 times per second.
Based on these results, we thought we could get away with a "warp-in" effect flying in maybe one or two hundred images and get decent frame rates. To make the effect somewhat predictable, we based the animation effect on clock time with the result that it drops frames rather than alters the speed of animation when the browser can't keep up with the requested workload.
Unfortunately, once we implemented the effect, we discovered that we started to get choppy performance with only forty or so images (all of our tests are using recent-model MacBook Pros running OS X and Firefox 3.5 or Safari 4). Our test images were 32x32, but once we switched to 128x128 images, performance suffered dramatically. We haven't looked into it further, but the degradation may be linear according to image size.
We had always planned on caching aggressively, but these results indicated just how much caching we'd have to do: lots.
So we implemented the directory in such a way that at any time, we can cache the state of the canvas animation and exclude arbitrary elements from the cache. This is how we implement various features like selecting a subset of the items and moving them to the center of the screen when you search the directory, for example:
We also added a staged introductory fly-in effect where only a subset of the tools fly in and we cache the screen state and then fly in others, keeping the overall number of items to animate low--but the effect is presently disabled. Look for it in a future release as we expand the catalog of tools further. We'll have to work something out because flying just 70 items at once produces choppy animations on the fastest hardware using the fastest browsers available.
For the time-based animations, we implemented a simple timing framework. We wanted to grab an off-the-shelf library, but of the half-dozen JS animation frameworks we analyzed, all of them assumed we were animating DOM nodes or changing single object properties, which made their use somewhat obtuse. We really just wanted a simple callback for each frame in the animation. (We also grabbed the GX framework's easy-to-grab ports of Robert Penner's easing equations.) We'd love to replace our timing framework with something more sophisticated and actively maintained; let us know if you've got something we can use. In particular, we'd like a framework that intelligently reports the minimum resolution required by all currently scheduled timing jobs.
On that note, the other interesting bit for us was working out how often to repaint the canvas. After experimentation, we settled on using setInterval to repaint the scene every 20 ms. This has the unfortunate side effect of hitting the CPU rather hard during the animations and so forth.
Future
We're really excited to add a bunch of community features to the directory. We want folks to vote on tools, comment on them, submit and maintain them, and so forth. But in addition to that, we want to enable sub-universes; e.g., we want to track plug-ins for tools like Prototype, jQuery or Firebug so you can explore those universes within the framework of the overall directory. And if there's interest, we'd love to make it even more general and release the "universe browser" framework for anyone that wants to use this interface to explore taxonomies.
On a technical note, we're really keen to see how the DOM would perform relative to canvas, and how 3D approaches (e.g., using Mozilla Firefox and Google Chrome's 3D support) work out. Oh, and we're going to release an accessible, non-graphical version of the directory soon as well.
Please tell us what you think, and we hope all of us will be able to make use of this framework to help keep track of the exploding universe of web developer tools. Thanks!
On the back of the first Jetpack announcement, we see new version announced, 0.2 that adds slidebars, jetpack.future, and persistent storage.
Slidebar isn't a spelling mistake, but a slightly different take on the traditional sidebar. Check out Aza in his screencast to see them in action, and wait for the part where he sucks in a playing video and lets you continue to browse the Web elsewhere.
but you have to use another new feature of Jetpack 0.2.... future:
Jetpack is two things at once: it is a platform for experimentation and it is also a solid set of APIs that anyone to easily build new Firefox features. To enable Jetpack to be both stable and — at the same time — to experiment with not-quite-yet-ready features we’ve added the ability to import new features from the “future”.
Slidebars, for example, are still highly experimental. To use them, you need to import them from the future first.
Read more about future in the Jetpack enhancement proposal (JEP) for jetpack.future.
jetpack.future.import("slideBar")
Persistent Storage and Clipboard Support
One of the most requested features in the Jetpack development mailing list was for the ability to persistently store data across restarts.
We’ve added simple storage to the future module. The API is defined in the storage JEP. Using it as simple as:
jetpack.future.import("storage.simple");
var db = jetpack.storage.simple;
var data = {name: "Firefox", twitter: "@firefox"};
db.set( "friend", data );
Kevin Decker has released FireDiff a very cool Firebug extension that tracks changes to the page and CSS.
Firediff implements a change monitor that records all of the changes made by firebug and the application itself to CSS and the DOM. This provides insight into the functionality of the application as well as provide a record of the changes that were required to debug and tweak the page’s display.
The release, which you can find here uses recent features of the latest Firebug 1.4 code. Early days!
We’ve started to see more and more libraries being built to support use cases with Canvas in a 2D context but we really want to take things to the next level and start to allow people to use 3D capabilities as well. Accelerated 3D graphics with the super-fast next-generation JavaScript engines from nearly every web browser vendor means that we’re going to be able to start to see more and more advanced applications written using open web technologies. 3D is a huge part of that story and we’re happy to bring our proposal to the table.
The proposed spec (found in one of vlad’s post on 3D Canvas) is a pretty light wrapper on top of OpenGL ES 2.0, with some changes to support some JavaScript pleasantries. OpenGL ES is a decent starting point, which is why we picked it. OpenGL is supported as part of every major operating system and in it’s being picked up as a standard on mobile devices as well. Compared to the full OpenGL spec, the ES variant is a smaller subset that reflects the reality of what’s being used on the ground and most hardware and software vendors have actually been re-tooling to support OpenGL ES with support for older versions of full OpenGL emulated on top of OpenGL ES. Mixed with the fact that there’s a decent amount of knowledge out there in the industry of how to use OpenGL, we think that this smooths the integration between the current set of OpenGL users and larger web developer community.
And, there is the link back to Vladimir Vuki?evi?, the engineer who did the initial work (and who has been a huge help for Ben and I at Mozilla wrt Canvas and much more).
This is great stuff, and is it is important to clarify that this isn't about 3D virtual worlds, like some people think. This isn't VRML. The iPhone and the Mac are doing really nice 3D effects all the time these days. Close a window in OS X / Vista. Launch and quit Time Machine.
I am also glad to see OpenGL ES instead of yet another attempt at doing the 3D. There are a lot of tools and mindshare around this, and people will build great libraries on top of it I am sure for particular niches (apply some effects etc) and maybe we can get some uplift to CSS itself :) Oh, and i am really glad to see Google involved too!
I also saw Ryan Stewart weighing in and liked some of what he had to say, but was surprised by:
So it’s unfortunate to see that even the browser vendors have given up on moving the open web forward through standards. Whether it’s the WHATWG versus the W3C or the trials and tribulations of actually implementing HTML5, things are very broken and everyone is moving on regardless. I don’t blame any of them, but it doesn’t seem like it’s good for web developers.
Standards groups aren't the place to innovate. Browsers should be creating compelling features, other browsers should copy the good ones, and then we can standardize. XMLHttpRequest wasn't grown in the W3C. The cool CSS ideas that have been implemented in multiple browsers recently weren't either. Browsers need to push more, not less. And, then we need the standards groups to rally and try to turn the -vendor-bar-baz into bar-baz. Giving Web developers more APIs is good for Web developers!
Sometimes you find leftovers of old technology in browsers that blow your mind. One of these "ghost in the machine" problems exists in Firefox: if you use window.sun or function sun() in JavaScript you effectively start the Java VM.
There are a few "magic" properties on Mozilla's DOMWindow interface for supporting LiveConnect that will initialize the Java plugin and all the baggage that comes with it (which, with modern Java plugins, means launching java.exe as a subprocess). Looking up these properties on the window object is all it takes.
Ben and I are excited to be releasing the first concept out of the Mozilla Developer Lab. As you know, we are big believers in the Open Web. Chris Wilson mentioned that many people are still building Web applications on top of browser technology from yester year. What if we built on more leading edge browser technology? As a challenge, we wanted to take on an interesting project that you would normally thing of as a desktop application, and see if it would fly on the Web.
Being developers, why not develop something that we know and use every day. Our code editor. There are great editors out there, and we are partial to many. From Vi and Emacs, to Textmate and IntelliJ IDEA.
We have all seen enhanced textarea and div code editors, and while some have done a great job with them, they often seem to fall down in performance with large files and have strange bugs that make them more of a toy than you would like.
How could we change this? What if we used Canvas? That question lead to our Bespin announcement at Mozilla Labs today. What would our dream editor be like?
Let's get to the meat. To check out Bespin yourself, fire up a browser that supports Canvas, and the text rendering portion of Canvas. We have tested Bespin on Firefox 3+ and WebKit Nightly, which both support the feature. Link over to bespin.mozilla.com and signup.
Once logged in you will see a dashboard view of your projects, and a sample project will be sitting there waiting for you. Navigate into the project and open up one of the files via double click. You will be taken into the code editor itself. Tinker around. Try out the command line at the bottom (try the help command to see what is out there).
Even though this is a tech preview, where the goal was to share it with the community, we wanted to make the editor as solid as possible. It had to scale to a large number of lines and continue to remain very responsive.
Over in the dashboard, you will notice some interesting UI elements. Shrink the width of the file panes and the filenames will be truncated in the middle a la Mac OS X (e.g. Take a file "syntaxhighligher.js" that doesn't have room and becomes "syntax...r.js" instead of a simpler "...ghligher.js"). The open sessions tabs at the bottom can be moved around and as more space is made available, they offer more information and change font size. This is all part of Thunderhead, a very early fun experiment to create a Canvas GUI toolkit. We will blog more about that later.
To see this in action, please check out this video of us showing the tool in action:
It has been a lot of fun building the tool. A lightbulb went off when you see the power of having a tool written in the platform that you write code in all day. You can easily extend and tweak it to your whim. Extensibility has been a core guideline for us. The command line gives us an easy way to add functionality (Ubiquity showed us the way here). Bespin commands look like Ubiquity commands, and we want to fully integrate them. We also made a big use out of custom events as a way to loosely couple code to functionality.
This means that you can write code that listens to editor events and does something new. On the other side of the coin, you can fire of events and the editor will consume them and do the right thing.
If you wanted to add some functionality whenever a new file is loaded into the editor, you would listen for an open success event. Here is an example of us doing just that in our command line object, to tell the user that something has been opened:
We have a lot to share about our experience building Bespin, and we will be posting a lot about them in the future. For now though, we want to hear from you. What do you think? What would you like to see? Have some cool concepts and features? Want to join us hacking on your tool? Have a project that you would like to embed the Bespin editor in? Let us know!
More resources
Check out our main announcement post has a lot more details on the vision and why we are doing this.
If you do any web development, chances are you know checkboxes and radio buttons can have two states: checked and unchecked. But in the case of checkboxes, you may want to indicate to the user that they are half-way between those states, for example when you have a master checkbox above many other checkboxes of singular items. This is now possible on Trunk (Firefox 3.2) thanks to the implementation of the HTML5 "indeterminate" DOM property. All it takes is a bit of script:
Mozilla is big on tinkering--making things your own. They recently released a marketplace for their community to upload its own shirt designs. But because they based it on the Ajax-heavy Zazzle platform, consumers can customize the shirts in a variety of ways. We thought this made for a good opportunity to take a closer look at Zazzle.
Easy Zooming
In the overview page showing different shirt designs, simply mousing over a shirt lets you zoom in on it in a smooth, easy motion.
Clicking into a shirt gives more Ajax goodness, like an alternate zooming interface showing the full-view and the detail simultaneously:
And finally, it has a shirt manipulation interface, though most of the design manipulation occurs on the server, it is sent back without a page reload, as we would expect:
Zazzle is built on the UIZE (pronounced "you-eyes") Ajax framework which we covered briefly in 2006 and have yet to revisit. We're not sure if UIZE is used by anyone but Zazzle, but it's got a pretty nice website, docs, widgets, basic effects, an event system, and an inheritance system. We'll have to give it a closer look!
