Mozilla

Featured Articles

Sort by:

View:

  1. Mozilla Labs Apps Developer Preview and documentation are here!

    The Mozilla Labs Apps project

     

    The Mozilla Labs Apps project enters a new phase with today’s launch of the Apps Developer Preview and App Development documentation in the Apps Developer Community on MDN.

    The tools and resources in the MDN Apps Developer Community documentation enable developers to create rich, cross-platform and cross-device app experiences using web standards and open technologies such as HTML5, CSS and JavaScript. The Mozilla Labs Apps project also aims to create a rich distributed ecosystem of app stores including a Mozilla HTML5 app marketplace to launch in 2012.

    To get started, sign up for the Mozilla Labs Apps Developer Preview, where you can test the features of the marketplace app-submission and sale process. The preview is limited to 3,000 developers on a first-come, first-served basis, so be sure to reserve your spot now.

    Visit apps-preview.mozilla.org to register now.

    If you are a Firefox user, please install the Mozilla Labs App Runtime Add-on, and if you are an Android user, please install the Mozilla Labs App Runtime application before you sign up for the Developer Preview. If you currently do not use Firefox or Android, go directly to the Apps Developer Preview.

    Your installed HTML5 apps can be found at myapps.mozillalabs.com

    Why is Mozilla focusing on apps?

     

    As part of Mozilla’s mission to make the web better we believe that apps should be available on any modern web-connected device, operating system or browser, allowing billions of people worldwide to use and interact with apps.

    Today, apps are tied to closed ecosystems. Apps also can’t be used across all devices; data within apps is silo-ed and inaccessible to other apps or Web services; and user choice is limited and undervalued.

    In an open ecosystem, developers should have the ability to build apps using open Web technologies and resources. They should then be able to distribute and sell those apps with the reach, flexibility and choice that the Web provides.

  2. Congrats to our October Dev Derby winners!

    Responsive design is more important than ever as people experience the Web on a variety of devices. Web developers can now take advantage of CSS Media Queries to build sites and applications that can be viewed on different screen sizes. So we decided to focus on that for the October Dev Derby.

    For this challenge, developers submitted 15 demos to show what you can do with CSS Media Queries. Check them out so see how they present unique styles and layouts in response to changes in viewing area.

    It was a fairly close race, so join us in congratulating the winners circle:
    October Dev Derby winners - CSS Media Queries

    1st Place: CSS3 Cherry Blossom – Media queries by elufo
    2nd Place: Santa’s Media Queries by tuxie
    3rd Place: Too many fish is the sea by michal.b

    Runners-up:
    Responsive 3D-Models For Any Device
    Spriting with CSS Media Queries

    Thanks to everyone that participated in the October Dev Derby! Only a couple of days left to participate in the November Dev Derby, so get your Canvas demos in now. Otherwise, start experimenting with IndexedDB for December.

    NOTE: We recently updated our Dev Derby rules to allow developers to participate in multiple contests until they win 1st place. That means if you’ve submitted awesome demos and come up short in the past, you still have a chance to win that top spot in future Dev Derbies… so keep those demos coming!

  3. Firefox – tons of tools for web developers!

    One of the goals of Firefox have always been to make the lives of web developers as easy and productive as possible, by providing tools and a very extensible web browser to enable people to create amazing things. The idea here is to list a lot of the tools and options available to you as web developers using Firefox.

    Continued…

  4. Webinar: IndexedDB with Jonas Sicking

    Update 2011-12-20: The video recording of this webinar is now available:

    IndexedDB is the emerging standard for structured client-side data storage. The IndexedDB standard is supported by current versions of Firefox and Chrome, and support for it is expected in Internet Explorer 10.

    With this growing maturity and support, it’s time to start experimenting with what IndexedDB can do for Web applications. Working with IndexedDB requires a shift in mindset for many Web developers, as it is more similar to “NoSQL” systems like CouchDB or MongoDB than to traditional relational databases.

    IndexedDB will be the theme for December’s MDN DevDerby. And to kick off the theme for the month, on December 1st, we’re offering an MDN Webinar on IndexedDB with Jonas Sicking, one of the editors of the IndexedDB draft standard and one of the implementors of IndexedDB in Gecko.

    When
    December 1st, at 9:00 a.m. US Pacific Time (17:00 UTC). Add this event to your Google calendar:
    Where
    Air Mozilla, with text chat on #airmozilla on irc.mozilla.org. (There’s an IRC widget on the Air Mozilla page if you need it.)

    We’ll record this session for those who can’t attend (or can’t use Flash, which is currently used by Air Mozilla for live streaming video).

    We’d like to get a rough estimate of how many people will be attending. If you happen to use Plancast, and you plan to attend the seminar, please join the event on Plancast.

  5. Developer Tools in Firefox Aurora 10

    The Preview You Can Use Now

    Mozilla is building a collection of stable, fast and usable developer tools that ship with the browser. I’d like to introduce a collection of improvements that are scheduled to be released in final form on January 31, 2012.

    But, you can get them now by downloading the Firefox Aurora channel. I personally find Aurora builds to be quite stable and usable for general browsing and web development. Give it a try and see what you think. You can install Aurora alongside your stable release of Firefox.

    The New Page Inspector

    Inspect Element Context Menu

    Using built-in tools, you can now peek into your page’s structure and layout. Choose “Inspect” from the “Web Developer” menu, or press the handy ctrl-shift-I (cmd-shift-I on Mac) keyboard shortcut, and you can visually select the page element that is of interest to you.

    You’ll also find a new “Inspect Element” context menu item that lets you immediately select the element that’s under your cursor.

    When you’re inspecting a page, you’ll see something like this:

    We overlay the page to highlight the element that you’re working with (1). The highlighter also shows you the tag, ID and classes associated with the page element you’re viewing.

    At the bottom of the window, there’s a toolbar that gives you options for changing or working with the selected element. Starting from the left, there’s a close button to close the page inspector and return to normal browsing. The “Inspect” button toggles visual selection mode so that you can highlight another element. ProTip: pressing the ESC key also switches modes.

    We call the next part of the toolbar the “breadcrumbs”. They show you where you are in the HTML structure and let you quickly switch to another element. The selected element is the dark “pushed” button. To the left of it are its parents, and to the right one of its children. Just click one of the buttons to move between the page elements. If you click and hold a button, you get a menu that lets you select from the siblings of the element listed on the button. The breadcrumbs make navigation quick without taking up much of your screen.

    HTML

    Sometimes looking at the HTML representation of a page is the quickest way to figure out what’s going on. Click the HTML button and that’s the view you’ll get. There’s a resizer on the right side of the toolbar to set just how much space you want for the HTML view. Also, clicking on a node in the HTML view will select that element for further inspection. ProTip: ctrl-H toggles the HTML view.

    Styles

    Last, but definitely not least, is the Style view. This lets you dive in, explore and experiment with your CSS. It offers two separate views of the CSS attached to the selected element: a CSS rules-based view (left, above), and a properties-based view (right, above).

    The rules view is organized much like your stylesheets, showing all of the rules that apply to the element and all of those properties that those rules give you. Properties that are overridden are crossed out. You can toggle any single property easily using the checkbox to the left of it. A single click on a property name or value lets you edit it and see the results immediately on the page. If you click anywhere on the line with the brace at the bottom of the rule, you can add a new property there.

    On a page with lots of styles, you sometimes just want to find out what the font-size is set to. That’s where the property view comes in. You can expand the “font-size” property and see how its set and which stylesheet set it. By default, only styles that are set in your stylesheets will be displayed (so you don’t get browser defaults listed). If you have a lot of properties listed, as you might if you use a reset stylesheet, you can quickly find what you’re looking for by typing in the search box.

    ctrl-S toggles the Style view.

    Web Console + Page Inspector: Great Together

    The Web Console is available whenever you want it, even when you’re using the page inspector. If you have an element selected, that element is available to JavaScript in the console using the variable $0.

    Scratchpad

    The Scratchpad feature, which we released in August, gives you a very friendly way to experiment with JavaScript. Rather than being confined to a small input box, you get a whole editor window to work with. Now, Scratchpad uses the Orion code editor to provide syntax highlighting, better indentation and other features you’d expect from a modern code editor.

    Scratchpad is now wired into Firefox’s “session restore” feature. This means that you can try out a bunch of code in Scratchpad and if you restart Firefox, restoring your session will also bring back your Scratchpad. Of course, you can always save and reload your Scratchpad files, just as you could before.

    If you are only doing web development, we’ve streamlined the user interface. If you’re doing Firefox add-on development, you owe it to yourself to set devtools.chrome.enabled to true in about:config. That setting allows Scratchpad to run code in a privileged browser context and not just against the current web page.

    The console Object

    We’ve been building out the console object that you call from your JavaScript code or use at the Web Console’s JavaScript input. It is now in line with the de facto standard, implementing the methods that are standard across browsers. Firebug has a couple of others that we don’t implement yet (console.table, console.profile, console.dirxml), but the commonly used methods are there.

    More Is On The Way

    All of these features are available now in Firefox Aurora builds. We’re working on getting more new features together for you for the next Aurora.

    Check out our Get Involved page to see how you can provide feedback and help make these tools even better.


    Footnotes:

    1. Other web developer tools make changes to your page (for example, adding a class) to make the selected element visible. Firefox’s highlighter does its work without making any changes to your content .↩

  6. Announcing Firefox Aurora 10

    We’re happy to announce the availability of Aurora 10.
    (Download and Test Aurora 10)

    In additional to the normal improvements that you’ve come to expect like performance, security and bug fixes, Aurora 10 focuses in HTML5 enhancements.

    New additions

    Developer Tools

    Aurora 10 also implements incremental enhancements like IndexedDB setVersion API changes. Ongoing detailed attention to evolving specifications help to keep Firefox at the front of the Web revolution. (Read more about IndexedDB on MDN.)

    DOM

    • We now fire a “load” event on stylesheet linking when the sheet load finishes or “error” if the load fails.
    • We turn the POSTDATA prompt into an information page (when navigating in session history).
    • We only forward event attributes on body/frameset to the window if we also forward the corresponding on* property.
    • We no longer allow more than one call to window.open() when we allow popups.
    • We fixed a bug where a success callback never fired when a position update is triggered after getCurrentPosition().
    • We removed replaceWholeText().
    • We fixed an error with createPattern(zero-size canvas).
    • We now handle putImageData(nonfinite) correctly.
    • We now throw INVALID_STATE_ERR when dispatching uninitialized events.
    • We’ve made Document.documentURI readonly.
    • We fixed document.importNode to comply with optional argument omitted.

    Web workers

    • We now allow data URLs.
    • We implemented event.stopImmediatePropagation in workers.
    • We made XHR2 response/responseType work in Web Workers.

    Graphics

    • We implement the WebGL OES_standard_derivatives extension.
    • We implement minimal-capabilities WebGL mode.

    JavaScript

    • The function caller property no longer skips over eval frames.
    • We fixed E4X syntax so that it is not accepted in ES5 strict mode.
    • weakmap.set no longer returns itself instead of undefined.
    • We implemented the battery API.

    Offline: IndexedDB enhancements

    • IndexedDB setVersion API changes
    • Added support for IDBObjectStore/IDBIndex.count
    • Various methods accept both keys and KeyRanges.
    • Added support for IDBCursor.advance.
    • Implemented deleteDatabase.
    • objectStoreNames are no longer updated on closed databases when another connection adds or removes object stores
    • IDBObjectStore.delete and IDBCursor.delete now return undefined.
    • No longer throws an error if there are unknown properties in the options objects to createObjectStore/createIndex.
    • We now the errorCode to “ABORT_ERR” for all pending requests when IDBTransaction.abort() is called.
    • Fixed the sort order for indexes.

    Layout

    • We have updated the current rule for handling malformed media queries.
    • We now support the HTML5 <bdi> element and CSS property unicode-bidi: isolate.
    • The CSS3 implementation now supports unicode-bidi: plaintext.

    Media

    • Implemented Document.mozFullScreenEnabled.
    • Enabled the DOM full-screen API on desktop Firefox by default.
  7. Located: Winners of the September Dev Derby on Geolocation.

    With more people going mobile and taking the Web with them, we thought Geolocation was a great topic for the September Dev Derby.

    Web developers explored a number of ways to bring your physical location into the Web experience and we had 16 demos submitted for the Dev Derby.

    Voting was tough this month, but once the votes were counted, we had our winners circle:
    Winners of the September Dev Derby - Geolocation

    1st Place: Urban arteries by Jaume Sánchez aka spite
    2nd Place: I Need A… by David aka d-b-f
    3rd Place: Find Street Art by Aaron Has

    Runners-up:
    Geosocial
    Geoapp

    Thanks to everyone that participated in the September Dev Derby and congratulations to the winners! A special shout out to Jaume for taking 1st place after submitting amazing demos for the past three Dev Derbies. Check out spite’s MDN profile to see what he’s done in the past.

    NOTE: We recently updated our Dev Derby rules to allow developers to participate in multiple contests until they win 1st place. That means if you’ve submitted awesome demos and come up short in the past, you still have a chance to win that top spot in future Dev Derbies… so keep those demos coming!

    If you’re working on CSS Media Queries, you have a few more days to join the October Dev Derby.

    Or get ready for the joy of painting in the November Dev Derby with Canvas. We’re looking forward to seeing some creative demos next month. So hack on!

  8. Ben Adida on BrowserID and identity

    This is the second installment of Mission:Mozilla, a series of interviews that link Mozillians, the technology they produce and the Mozilla mission. Today Ben Adida is in the hot seat to discuss BrowserID, Mozilla’s identity initiative.

    Tristan Nitot – Hi Ben, can you briefly introduce yourself?

    Ben Adida – I’ve been hacking since high school and, since college, I’ve been fascinated with cryptography, security, and controlling my data. I built my first DB-backed web site before cookies. I ran my own IMAP mail server starting in 1997 because no one else was doing it the way I wanted it. I started an open-source web dev shop in 2000, went back to grad school in 2003 to work on secure voting, explored security and privacy of health data at Harvard Med for a few years, and joined Mozilla in March 2011. I’m now Tech Lead on Identity and User Data, and I’m having a blast.

    TN – Oh my… running your own IMAP server in 1997? That’s the kind of thing that gives instant nerd credibility ;-)

    BA – Oh yes, big nerd and proud of it!

    TN – So you’re now with Mozilla, focusing on Identity and User data. Can you update us on what’s Mozilla is doing on these fronts?

    BA – Everyone I talk to within Mozilla realizes that the Open Web depends on more than just the Firefox web browser. People are storing massive quantities of their personal data online, using dozens of services, and an open browser is not enough to ensure that they have true choice, true control, that they can shape the Web to their liking. So we need to be working towards providing user choice in web-based services, too. The first piece of the puzzle is a usable, federated, and distributed identity system. That’s what we’re doing with BrowserID.

    TN – “federated, distributed”, with users having control… Sounds like the original pillars of the Web, right? I mean, as opposed to what we tend to see these days, with identity being concentrated into the hands of very large commercial organizations… How do you plan to achieve this?

    BA – That’s right, distributed/federated *is* the way of the Web, but when you look at today’s identity solutions, most are incredibly centralized, and those that are more distributed in terms of protocol tend to become centralized in implementation because of the so-called NASCAR problem: you get to log in with Google or Yahoo, and if you’re *really* knowledgeable then maybe you can log in with your own Identity Provider. We think we can do better for users and developers in terms of ease of use and adoption.

    TN – And what about privacy?

    BA – We’ve specifically designed BrowserID to reduce the amount of private data that changes hands to the bare minimum required for authentication. For example, in every other web-based identity system today, the site you log into phones home to your identity provider. In the real world, the equivalent is: you check into a hotel, present your ID to confirm your name, and the receptionist calls the issuing government agency and says “Hi, this is the Hyatt San Francisco, Tristan is checking in just now, is that okay?” Why does the government agency or, in the case of a privately issued identifier, the commercial entity, need to know where and when you’re checking in? In the real world, the receptionist just checks the seal on the ID without phoning anyone. BrowserID recreates this more restrained, more privacy-protecting data flow for web logins.

    TN – So how do you manage to get the best of both worlds: user experience and user control?

    BA – First we’re making the browser an important part of the protocol. After all, the browser is the User’s Agent. Isn’t it a little bit silly on today’s Web that you typically have a tab open to your gmail, and then another site asks you to log in with Google or Yahoo? Why can’t the browser help coordinate those two tabs? You’re logged into gmail, of course you have a gmail email address you can use to authenticate! And in the enterprise setting, you’re logged into your company webmail, of course you can authenticate using that enterprise identity! The browser can help reduce user complexity significantly.

    TN – But I could want to use another email address, than the one I use for my Webmail…

    BA – Right, so we’re always going to give users a choice. Users can choose exactly which persona they want to present. And one major BrowserID design point is simply that users understand email addresses as personas. They typically have home and work email addresses, and they don’t use them the same way. If they have a moonlighting job, they often have a separate email address for that. So BrowserID is based on this concept users already understand: logging in is simply delivering an email address to a web site in a way that the web site can easily verify.

    TN – Cool. Say I’m a Web developer that wants to use BrowserID on my site. How hard is that? How much do I have to relinquish control of my users to Mozilla?

    BA – It takes about 5 lines of JavaScript and 10 lines of backend code to integrate BrowserID, and it works today. It’s by far the easiest of the available identity solutions. In the short term, it means you’re relying on Mozilla servers to provide the BrowserID interface and verify users’ email addresses. That said, this is only temporary scaffolding for our distributed system.

    TN – But as BrowserID becomes native in browsers and identity providers appear, this will change?

    BA – We’ve taken great care to design the system so that, as browsers begin to support the BrowserID APIs natively, we can remove our scaffolding and leave standing a truly distributed protocol. Best of all, web sites don’t have to change a line of code for that to happen: as the identity providers and browsers start supporting BrowserID, our scaffolding automatically fades away. And let’s say you’re a web developer and you want to stop using BrowserID for whatever reason: just send your users an email with their new password, and you’re done. No other identity system minimizes lock-in this much, for both users and web developers.

    TN – So minimizing lock-in is part of the BrowserID design goals?

    BA – Absolutely! This is part of our mission and manifesto. We don’t want to own users, we want to empower them. Mozilla is in a unique position to build this kind of identity system because, as we all like to say, Mozilla answers only to users, and we can leverage Firefox to deploy these pro-user designs.

    TN – Fantastic! What would you recommend to Websites who want to do a test-run on their site? And for users who want to experience BrowserID right away?

    BA – Web developers can check out our documentation. Users can check out http://current.openphoto.me, a very promising distributed photo storage system shepherded by WebFWD that chose BrowserID. Just click the distinctive BrowserID login button to get a taste of the user experience.

    TN – I’m sure our readers will try it right away! Thanks a lot Ben for your time. Long live BrowserID!