Firefox

Firebug lives on in Firefox DevTools

As you might have heard already, Firebug has been discontinued as a separate Firefox add-on.

The reason for this huge change is Electrolysis, Mozilla’s project name for a redesign of Firefox architecture to improve responsiveness, stability, and security. Electrolysis’s multiprocess architecture makes it possible for Firefox to run its user interface (things like the address bar, the tabs and menus) in one process while the content (websites) runs in other processes. With multiprocess architecture, if a website crashes, it doesn’t also crash the whole browser.

Unfortunately, Firebug wasn’t designed with multiprocess in mind, and making it work in this new scenario would have required an extremely difficult and costly rewrite. The Firebug Working Group agreed they didn’t have enough resources to implement such a massive architectural change. Additionally, Firefox’s built-in developer tools have been gaining speed, so it made sense to base the next version of Firebug on these tools instead.

The decision was made that the next version of Firebug (codenamed Firebug.next) would build on top of Firefox DevTools, and Firebug would be merged into the built-in tools.

And perhaps most importantly, we joined forces to build the best developer tools together, rather than compete with each other. Many of Firebug’s core developers are on the DevTools team, including Jan ‘Honza’ Odvarko and Mike Ratcliffe. Other Firebug Working Group members like Sebastian Zartner and Florent Fayolle are also active DevTools contributors.

A huge thank you to them for bringing their expertise in browser developer tooling to the project!

In practical terms, what does it mean to merge Firebug into DevTools?

Several features have been absorbed: The DOM panel, the Firebug theme, Server-side log messages, the HTTP inspector (aka XHR Spy), and various popular add-ons like FireQuery, HAR export, and PixelPerfect. Also, over 40 bugs were fixed to close the gap between DevTools and Firebug.

For curious readers, a couple of articles on hacks.mozilla.org and on the Firebug blog go into more detail.

If you are switching now from Firebug to Firefox DevTools, you will of course notice differences. This migration guide can help you.

We understand that disruption is never really welcome, but we are working hard to ensure developers have the best possible tools, and sometimes this means we need to refocus and use resources wisely.

You can help: Tell us which features you need are missing. There are a few ways you can do this:

We are already tracking missing features on this bug, and so far you have told us that the most important are these:

We thank you for your loyalty and hope you understand why we’ve made this difficult decision. The Firebug spirit lives on in all of the browser developer tools we build and use today.

The Firefox DevTools and Firebug teams

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Firefox Hardware Report for Web Developers

Suppose you’re developing a sophisticated web game or application, and you’re wondering — will it actually be able to run? What hardware should I be targeting to get the widest possible audience? Existing hardware reports (such as those from Valve and Unity) are excellent, but represent a different group of hardware users than the majority of people who use the web.

We’ve been working on the next-generation web game platform for years now, and often receive questions from web developers about the hardware market. Today we’re releasing the Firefox Hardware Report to help answer those questions and inform your development decisions.

On this site you’ll find a variety of data points showing what hardware and OSes Firefox web users are using on the web, and trends over time. This includes CPU vendors, cores, and speeds; system memory; GPU vendors, models, and display resolution; Operating System architecture and market share; browser architecture share, and finally, Flash plugin availability. Some charts (such as the GPU models) have an expanded view showing all of the models captured. You’ll also discover all sorts of interesting stats — like 30% of Firefox users have 4 GB of RAM; that Intel makes 86% of users’ CPUs and 63% of their GPUs; or that the most popular screen resolution (with 33% of users) is 1366×768.

Firefox Hardware Survey

The Firefox Hardware Report is a public report of the hardware used by a representative sample of the population from Firefox’s desktop release channel. The source data for the Hardware Report was collected through the Firefox Telemetry system, which automatically collects browser and platform information from machines using Firefox. We use this data to prioritize development efforts and to power this report.

Once data is collected, we aggregate and anonymize it. During the aggregation step, less common screen resolutions and OS versions are handled as special cases — resolutions are rounded to the nearest hundred and version numbers are collapsed together in a generic group. Any reported configurations that account for less than 1% of the data are grouped together in an “Other” bucket. At the end of the process, the aggregated, anonymized data is exported to a JSON file and published on the report website.

To learn more about how we created this report, take a look at our blog post on the Mozilla Tech Medium. The code used to generate the reported data and website is available on GitHub.

This is just our first step, and we hope to expand this data set over time. In the meanwhile, please let us know what you think — is this data useful? What other data points might be helpful in the future? Do you have visualization suggestions? We look forward to your email feedback, with thanks!

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Async/Await Arrive in Firefox

The new async and await keywords—which make asynchronous code more concise, obvious, and maintainable—have arrived in Firefox 52. Currently available in the latest Developer Edition release, Firefox 52 is scheduled for general release in March 2017.

JavaScript owes its excellent single-threaded performance and responsiveness on the web to its pervasively asynchronous design. Unfortunately, that same design gives rise to “callback hell,” where sequential calls to asynchronous functions require deeply nested, hard-to-manage code, as seen in this slightly contrived example using the localforage library:

function foo(callback) {
  localforage.setItem('x',  Math.random(), function(err) {
    if (err) {
      console.error("Something went wrong:", err);
    } else {
      localforage.getItem('x', function(err, value) {
        if (err) {
          console.error("Something went wrong:", err);
        } else {
          console.log("The random number is:", value);
        }

        if (callback) {
          callback();
        }
      });
    }
  });
}

foo(function() { console.log("Done!"); });

If you glossed over that code, or didn’t immediately understand what it did, that’s the problem.

ES2015 began addressing this challenge by standardizing on Promises for chained, asynchronous functions. Since their introduction, Promises have become an integral part of new web standards, including fetch and service workers. They make it possible to rewrite the previous example as:

function foo() {
  return localforage.setItem('x', Math.random())
         .then(() => localforage.getItem('x'))
         .then((value) => console.log("The random number is:", value))
         .catch((err) => console.error("Something went wrong:", err));
}

foo().then(() => console.log("Done!"));

Thanks to Promises, the code doesn’t nest deeper with each successive call, and all of the error handling can be consolidated into a single case at the end of the chain.

Note that in the example above, foo() returns immediately, before localforage does its work. Because foo() itself returns a Promise, future callbacks can be scheduled for after it completes with the .then() method.

Semantically, the example above is much more straightforward, but syntactically, there’s still a lot to read and understand. The new async and await keywords are syntactic sugar on top of Promises to help make Promises more manageable:

async function foo() {
  try {
    await localforage.setItem('x', Math.random());
    let value = await localforage.getItem('x');
    console.log("The random number is:", value);
  } catch (err) {
    console.error("Something went wrong:", err);
  }
}

foo().then(() => console.log("Done!"));

The code above is functionally identical to the previous example, but it is much easier to understand and maintain, since the function body now resembles a common, synchronous function.

Functions marked async always return Promises, and thus calls to .then() work on their return value to schedule callbacks. Expressions prefixed with await effectively pause functions until the expression resolves. If an awaited expression encounters an error, then execution passes to the catch block. If uncaught, the returned Promise settles into a rejected state.

Similarly, instead of handling errors inside async functions, it’s possible to use normal .catch() methods on the return value instead:

async function foo() {
    await localforage.setItem('x', Math.random());
    let value = await localforage.getItem('x');
    console.log("The random number is:", value);
}

foo().catch(err => console.error("Something went wrong:", err))
     .then(() => console.log("Done!"));

For a more practical example, consider a function you might write to unsubscribe a user from web push notifications:

function unsubscribe() {
  return navigator.serviceWorker.ready
         .then(reg => reg.pushManager.getSubscription())
         .then(subscription => subscription.unsubscribe())
         .then(success => {
           if (!success) {
             throw "unsubscribe not successful";
           }
         });
}

With async and await, it becomes:

async function unsubscribe() {
  let reg = await navigator.serviceWorker.ready;
  let subscription = await reg.pushManager.getSubscription();
  let success = await subscription.unsubscribe();
  if (!success) {
    throw "unsubscribe not successful";
  }
}

Both function identically, but the latter example hides the complexities of Promises, and turns asynchronous code into code that reads (and executes) like synchronous code: from top to bottom, waiting for each line of code to fully resolve before moving on to the next line.

Native cross-browser support for async and await keywords is still nascent, but you can use them today with the help of a JavaScript transpiler like Babel, which can convert async / await to functionally equivalent, backward-compatible code.

To learn more about the async and await keywords, or Promises in general, check out the following resources:

Remember, async and await are just helpers for Promises: you can mix and match either syntax, and everything you learn about Promises applies directly to  async and await.

Special thanks to Jamund Ferguson for suggesting improvements to the code samples in this post.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

CSS Grid and Grid Highlighter Now in Firefox Developer Edition

CSS Grid has just been uplifted to Firefox 52 Developer Edition (download it here!). With Chrome (and hopefully Safari and Edge) implementations coming shortly, using grid to build websites will soon be possible in release browsers across the board.

Grid allows users to decouple HTML from layout concerns, expressing those concerns exclusively in CSS. It adapts to media queries and different contexts, making it a viable alternative to frameworks such as Twitter’s Bootstrap or Skeleton which rely on precise and tightly coupled class structure to define a content grid.

Reducing the risks of fragility, code bloat, and high maintenance costs inherent in how we currently build on the web, grid really does have the potential to change the way we do layouts. Jen Simmons calls it Real Art Direction for the Web and Rachel Andrew has built Grid by Example to inform, share, and evangelize it. If you’re new to grid, be sure to have a look.

As you can see in the video, the grid highlighter tool will help get you started illustrating the grid in-page as you’re working. Additional tooling is planned for the near future to continually improve working with grid.

To access this tool, make sure you’re running an up-to-date version of DevEdition. Next, open a page that is known to have grid code—we recommend one of these demos for this. Open the Inspector via Developer ? Inspector. Select an element with the property display: grid;. To toggle grid lines, click the icon next to “grid” which will persist the lines permanently.

The Firefox Developer Tools team have planned a series of improvements to make working with grid easier in the future. You can follow our progress through these bugs:

The metabug for tracking this work is bug 1181227.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

New Responsive Design Mode: RDM Lands in Firefox Dev Tools

Firefox Developer Tools now includes a completely redesigned Responsive Design Mode (RDM for short) that’s just landed in Firefox Developer Edition, thanks to hard work from the DevTools team.

In a mobile-first world, it’s essential to prioritize performance for low-bandwidth and offline mobile experiences and design progressive web apps that can deliver across a range of devices. We aim to design developer tools that prioritize empathy for users and developers. That’s why we’ve put so much effort into the Responsive Design Mode.

We want to make it easier for developers to build web experiences that load and respond on screens of all different sizes and support a multitude of browsers, platforms, and device types. RDM is a significant upgrade to the Firefox tools themselves, reflecting our commitment to people who build for the web.

To access the RDM tool, make sure you’re running an up-to-date version of DevEdition. Next, open any web page to view  the Responsive Design Mode via Developer ? Responsive Design Mode.

There’s a lot in this new tool, and many new features still to come. Check out the video walk-through to see the tool in action with all of its features enumerated, including:

  • Popular device emulation
  • Network throttling
  • Touch-event emulation
  • Ability to set DPR (device pixel ratio) of devices
  • Screenshotting devices at certain sizes

Firefox Developer Tools already has a series of improvements planned for the next release of Responsive Design Mode, including:

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Firefox 49 fixes sites designed with WebKit in mind, and more

Several recent articles on the Hacks blog explain why web developers should care about cross-browser compatibility and how great web developers achieve it. Web developers have a critical role in making the web work for everyone. And so do browser makers. As of today we’re introducing a number of compatibility features to the Gecko rendering engine, bringing us up to date with the WHATWG Compatibility Standard.

Some notable changes in this release include support for several -webkit- prefixes and WebKit-specific interfaces. These platform features are non-standard, vendor-specific, and quite prevalent.

Non-standard, incompatible CSS breaks websites for user agents designed around standards. When a browser that doesn’t support -webkit- prefixes (such as Firefox 48 and below) visits one of these sites, the web looks broken. This will be the case until those sites update their CSS. That’s why Firefox 49 includes the following changes to accommodate WebKit-specific content:

(in)Frequently Asked Questions (iFAQ):

Q. So, what does this mean for me?

A. As a user, improved compatibility with sites that were designed for WebKit browsers only, especially on mobile.
okcupid

As a developer, you might want to go back and add unprefixed equivalents to your -webkit-only CSS so we can remove these from the web platform one day in the future (theoretically). Pro Tip: Unprefixed properties always come last.

Q. Did you just break my site?

A. We hope not! But you can toggle this for testing with the following preference:

about:config?filter=layout.css.prefixes.webkit

If there’s a difference (for the worse!), please report bugs to bugzilla.mozilla.org and cc mitaylor@mozilla.com, or report them on webcompat.com.

Q. Should I only use -webkit- prefixes from now on?

A. No, that’s unnecessary and inadvisable. Keep using web standards and keep testing in multiple browsers. If you must use -webkit- prefixes (and there are fewer reasons to do so than ever before), make sure they’re above the unprefixed property in your CSS.

Full disclosure: Mike edits the Compatibility Standard, but there’s work to be done if you’d like to contribute!

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Shipping Rust in Firefox

TL;DR: Starting with Firefox 48, Mozilla is shipping its first production Rust code, with more to come!

Mozilla ? Rust

It’s hard to believe it’s been almost seven years since Mozilla Research first began sponsoring the development of Rust, at the time little more than an ambitious research experiment with a small but devoted community. Remarkably, despite a long history of inventions and discoveries, Rust’s key principles have remained constant. The Rust core team’s original vision—a safe alternative to C++ to make systems programmers more productive, mission-critical software less prone to memory exploits, and parallel algorithms more tractable—has been central to Mozilla’s interest in backing the Rust project and, ultimately, using Rust in production.

An equally promising development has been the fact that Rust’s safety and modern features are attracting new people to systems programming. For Mozilla, where community-based development is quite literally our mission, widening our circle is vital.

So I’m pleased to mark an important milestone: with Firefox 48, Mozilla will ship our first Rust component to all desktop platforms, and with Android support coming soon.

Building Rust into Mozilla’s media stack

One of the first groups at Mozilla to make use of Rust was the Media Playback team. Now, it’s certainly easy to see that media is at the heart of the modern Web experience. What may be less obvious to the non-paranoid is that every time a browser plays a seemingly innocuous video (say, a chameleon popping bubbles), it’s reading data delivered in a complex format and created by someone you don’t know and don’t trust. And as it turns out, media formats are known to have been used to trick decoders into exposing nasty security vulnerabilities that exploit memory management bugs in Web browsers’ implementation code.

This makes a memory-safe programming language like Rust a compelling addition to Mozilla’s tool-chest for protecting against potentially malicious media content on the Web. For this reason, Ralph Giles and Matthew Gregan built Mozilla’s first Rust media parser. And I’m happy to report that their code will be the first Rust component shipping in Firefox. For the Rust community as well, this is a real achievement: Rust code shipping to hundreds of millions of Firefox users. Our preliminary measurements show the Rust component performing beautifully and delivering identical results to the original C++ component it’s replacing—but now implemented in a memory-safe programming language.

Telemetry data for Firefox's first Rust component

Firefox telemetry data showing zero issues in over a billion uses of the new Rust code.

More to come!

Many people deserve huge thanks for getting us to this point. Ralph Giles and Matthew Gregan implemented the component, and Nathan Froyd, Nick Nethercote, Ted Mielczarek, Gregory Szorc, and Alex Crichton have been instrumental in integrating Rust into the Firefox build and tooling system and ensuring it can ship on all of our platforms.

Rust itself is the product of a tremendous, vibrant community. None of this work would have been possible without the incredible contributions of issues, design, code, and so much more of Rustaceans worldwide. As a Rustacean myself, I’d encourage you to come play with Rust. It’s a great time to get started, and increasingly, to get involved with a Mozilla project using Rust.

Seeing Rust code ship in production at Mozilla feels like the culmination of a long journey. But this is only the first step for Mozilla. Watch this space!

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Optimizing JavaScript Performance With Firefox Dev Tools

The Performance tool in Firefox Developer Tools offers a great way to diagnose slow-running JavaScript and provides insight into the general responsiveness and layout performance of your web site.

In this video screencast, I’ll go through the process of how to diagnose issues with slow code and how to fix those issues in your code. Watch me fix for a 2d canvas demo that’s so slow it can barely update after a few seconds. By running a performance analysis, I’ll show you a simple code tweak that makes the demo run well at real-time rates.

Relevant Links

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Trainspotting: Firefox 45

Trainspotting is a series of posts highlighting what’s new in release versions of Firefox. A new version of Firefox is shipped every six weeks – we at Mozilla call this pattern “release trains.”

March winds bring April showers, and also the latest and greatest version of Firefox! Let’s take a look at some of the new goodies and other changes in the browser.

Tab Sync

Location bar suggestions for tabs open on other devices

If you have tabs open in Firefox on another device, those tabs will now appear as suggestions in the Awesome Bar. It’s a fast way to pick up where you left off on your phone or work computer. You can also view the full list of tabs open on other devices via a toolbar button menu.

Developer Tools

negative filtering of requests in the network panel

You’ve been able to filter network requests by URL since Firefox 40, but now you’re able to filter out requests you’re not interested in by pre-pending ‘-‘ to your filter terms. Handy in long-lived single-page webapps where many requests occur over the duration of a page session.

Animation Panel Enhancements

animation property break-down

The animation panel has a few new tricks up its sleeve (sleeves? not sure how many limbs a devtool has). You can now view a list of individual properties being modified by each animation. The expanded view of the timeline also has markers for each keyframe that applies to the specific CSS property.

Also new in Firefox 45 is the ability to adjust the playback rate in the Animation Panel for fine-tuning those complex sequences in slow motion. Should speed up debugging quite a bit.

Goodbye Tab Groups

organize your tabs into groups using the Tab Groups extension

Hello Tab Groups! If you know about the Tab Groups feature in Firefox, there’s a pretty good chance you are a die-hard power user of the feature. That group, however, was a very small percentage of users, and the feature was removed to simplify Firefox’s code base. Never fear! Simultaneously, add-on developer Quicksaver stepped up and hosted the Tab Groups code into a Firefox extension! All the visual organizing, drag-n-dropping action is just as it was before. Kudos to Quicksaver for keeping the power-user dream alive!

There’s always more to talk about in a Firefox release than I have words for, and 45 is no exception. Check out the release notes for a high-level list of changes in the browser, or peruse the detailed list of developer facing changes on MDN.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Debugging Service Workers and Push with Firefox DevTools

Following the announcement of Web Push in Firefox 44, we’re now delivering the capability to develop and debug service workers and push notifications code with DevTools using Firefox Developer Edition 47.

Here’s a screencast that demonstrates the features described in this post:

Or if you prefer text, keep reading!

about:debugging

Service workers do not behave exactly as normal web workers, and their lifecycle is different, so we can’t show them alongside normal scripts in the Debugger tab of DevTools.

Instead, we’ve added a new dashboard that will collect all registered service workers and shared workers, amongst other debuggable items such as Add-ons.

Therefore, our debugging adventure starts by going to about:debugging in a new tab, and clicking on the Workers tab on the left.

about:debugging interface

Alternatively, you can access this dashboard by going to the Tools ? Web Developer ? Service Workers menu, or by clicking on the toolbar menu, then Developer, and finally Service Workers.

Accessing about:debugging using the application menuAccessing about:debugging with toolbar menu

Dashboard instant updates

The first time we access the dashboard “nothing yet” will be displayed under the Service Workers and Shared Workers sections. These sections will be updated automatically as workers get registered. The displayed buttons will change accordingly, showing Push and Debug if the worker is running, or just a Start button if the worker is registered, but inactive.

Try it! Open about:debugging in one window, and navigate to this simple service worker demo in another window. The service worker will be registered and displayed under the Service Workers section. No need for you to reload the dashboard!

Debugging service workers

To debug a service worker, the worker must already be running. Click on the associated Debug button, or Start the worker if it’s not running yet (as long as it has been registered, and thus is in the about:debugging Dashboard).

This will pop up a new window with the code of the service worker. Here you can do all the usual debugging you would expect: setting breakpoints, step-by-step execution, inspecting variables, etc.

Service Worker debugger pop up window

Push notifications

Code that uses the Web Push API can now be debugged as well, by setting a breakpoint in the listener for the push event of the service worker. When the push notification is received, the debugger will stop at the breakpoint.

Debugger stopped at the push event listener

This is very handy, but sometimes notifications can be delayed for reasons outside of our control, or the network might be temporarily unreachable. Luckily, you can still test code that relies on push events, by pressing the Push button on the worker.

This will send a push payload, and in turn, it will trigger the push event pretty much instantly. You can reduce your development time as you won’t have to wait for the server to deliver the push.

Debugging shared workers

There’s also support for debugging shared workers. The most important difference is that they will show up in their own dedicated section in about:debugging.

Debugging requests (and cached requests)

You can also now distinguish normal network requests from requests cached by the worker. These cached requests are displayed as Service Worker in the Transferred column, instead of displaying the amount of transferred data.

Network panel showing cached requests

Requests initiated by service workers can be intercepted and debugged by setting a breakpoint on the fetch event listener.

Stopping at the fetch event

We can inspect data such as the requested url, http headers, etc., by looking at the event object in the variables list when the debugger stops at the breakpoint.

Wrap up

Hopefully, this provides a good overview of the new features we’re working on.

The reference documentation for about:debugging is on MDN. If you want to learn more about service workers, you should check out the guide to Using Service Workers, and, of course, the Service Workers cookbook, which is loaded with great demos and examples.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)