DevTools

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)

Visualize animations easing in DevTools

The easing (or timing function) of an animation is what dictates the way it progresses through time.

For example, a linear easing means that an animation runs at the same speed throughout its duration. This means that if an element isn’t moving at first and then starts to move, it will do so instantly, as if it didn’t even need to accelerate. Often, web developers choose other easings that look more natural, more life-like. There are a few built-in ones like ease, ease-in, ease-out and ease-in-out and it’s even possible to create your own using the cubic-bezier() function.

It’s worth noting that the Inspector panel in Firefox already allows you to edit animations easing in its CSS rules view.

Starting with Firefox 52 the animation inspector panel now displays animations easing directly within its timeline:

timeline-easing

This is very useful to get more information about animations at a glance.

There is also a handy tooltip that appears when hovering over animations. It contains all the timing information you might need for a given animation: including its easing, as well as durations, iterations, delays, direction, etc.

timing-tooltip

Here are various examples of how easing is represented in the timeline:

  • An animation that repeats 3 times, with an ease-in-out easing:
    ease-in-out-3-iterations
  • An infinite animation, with linear easing:
    linear-infinite
  • An animation that repeats 5 times, with an alternate direction, ease easing and forwards filling:
    ease-alternate

And here is a video illustrating several types of easing in the animation inspector panel:

About delays

There are 2 types of delays you can use in animations: delay and end-delay.

The latter can only be used with animations created with the Web Animations API. End-delay is useful to synchronize several animations, e.g. when you want one animation to start exactly 1s after the first has ended.

Both the delay and end-delay can be positive or negative.

The animation inspector now also represents those delays visually. Here are a few examples:

  • Positive delay:
    positive-delay
  • Positive end-delay:
    positive-end-delay
  • Negative delay:
    negative-delay
  • Negative end-delay:
    negative-end-delay

Effect easing vs. keyframe easing

There are 2 ways to apply easing to an animation: either across the whole iteration of an animation, affecting all properties alike (effect easing), or between keyframes and only affecting the properties specified on those keyframes (keyframe easing).

CSS animations only allow for keyframe easing and this confuses a lot of people. Nearly everyone assumes that animation-timing-function does effect easing but it does keyframe easing instead. However, animations created using the Web Animations API can use both types of easing.

Right now, the animation inspector only displays effect easing. This means that even if you define a CSS animation with a non-linear animation-timing-function, the timeline will display a linear progression.

Bug 1309468 will address this and make keyframe easing visible in the animation inspector too. We welcome your thoughts and constructive feedback in the comments section here, or send a tweet to @FirefoxDevTools.

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)

Introducing DevTools Reload

As a way to encourage more open source developers to contribute to the evolution of Firefox Developer Tools, the DevTools team has built DevTools Reload, an add-on that removes some common barriers to entry.

It’s not unusual for mature Open Source projects to have large code bases. This can act as a barrier to entry for new contributors. It might feel as though so much code is going to take a long time to learn, so even if the best way to get started is by fixing simple bugs, the task can seem overwhelming due to the size of the code base.

Another challenge with large code bases is that they often take a great deal of time to download and compile, which further discourages new contributors from taking part. Even if someone decides to dive in at this point, long recompile times after making simple changes can discourage even the most patient of developers.

DevTools Reload allows developers to make changes to the JavaScript and CSS source files, and by pressing a short-cut key combination, automatically reload the tools with all the new changes. Firefox thinks the tools should be hackable just like the Web.

This approach is convenient for making simple fixes to Firefox dev tools, and provides almost instant feedback to the developer who is making the change, allowing for quick iteration and experimentation on possible solutions.

Here’s a short screencast showing how to install the add-on on Firefox Nightly and demonstrating the feature. Or, if you prefer the written word, we also have some guidance on how to get started.

This feature is fairly new, and is still under development, so you might find rough edges and inconsistencies. Please file bugs if you find something doesn’t quite work as you expect it, or get in touch. You can follow the DevTools team (@firefoxdevtools) for more updates. Make sure to submit your contributions to the tools through bugzilla.

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)

Firebug & DevTools Integration

You might have already heard about our effort to unify native Firefox Developer tools (DevTools) and Firebug. We’ve been working hard to port all favorite Firebug features into native DevTools, make them multi-process compatible, and available for remote debugging (i.e., e10s compatible). We’ve been also working hard to make the transition path from Firebug to DevTools as simple and smooth as possible. Yes, as we’ve mentioned before, we’re focused on developing one great tool for developers!

So, let’s see how it looks now.

The main goal of next-generation Firebug is to help users feel at home when working with native DevTools. This is where Firebug 3 (aka Firebug.next) comes in. Firebug 3 is not another developer tool, it is rather a thin layer built on top of DevTools, providing a new theme that makes DevTools look like Firebug. There are also a few additional features, that we’ll port into DevTools step by step.

If you are missing any features (e.g. some of those you’ve been using in previous versions of Firebug), you should expect them to be part of DevTools in the future.

Firebug 3

Take a look at the screenshot below showing what DevTools look like if you install Firebug 3 (first beta). Does this look familiar?

Firebug 3 (aka Firebug.next)

Firebug 3 (aka Firebug.next) isn’t distributed through AMO yet, so you might need to set the xpinstall.signatures.required preference (through about:config) to false.

It’s the Firebug theme ported into DevTools to bring some UI and layout advantages. There is also the well-known Firebug start button in the Firefox toolbar, which represents the entry point to the developer toolbox.

See, the Firebug Theme option is currently active.

Firebug Start Button

The process for entering your handy tools is exactly the same: you can either press the start button or the F12 key.

You might be a fan of the DOM panel used to inspect the document object model of the page you’re on. It isn’t supported natively (yet) and so, Firebug offers it to you.

DOM panel

XHR previews in the Console panel (requested many times) are also supported.

XHR Previews

Some of the most popular extensions have been re-implemented on top of DevTools. Not only does this keep popular features alive, these implementations also provide great examples of how you can make new extensions directly for DevTools. Firebug isn’t required to run these extensions.

If you are an extension developer you might be interested in some examples and links to other resources helping to understand how to extend DevTools.

Let’s see what extensions are available.

FireQuery extension

FireQuery is a Firefox plugin for jQuery development built on top of DevTools in Firefox. Firebug 3 isn’t required, but some of the screenshots below show DevTools with the Firebug theme activated (the other themes, Light and Dark, are also supported).

Elements with jQuery data associated display a little envelope icon in the Console panel. You can inspect it by clicking on the icon. There is also a jQuerify button in the Console panel toolbar and you can use it to load jQuery into the current page.

FireQuery extension

The Inspector panel also displays the envelope icon for elements with jQuery data. Clicking the icon opens a popup with details.

FireQuery Inspector panel

PixelPerfect extension

Pixel Perfect is a Firefox extension that allows web developers and designers to easily overlay a web composition with semi-transparent layers (images). These layers can then be used for per pixel comparison between the page and a layer.

There is a Pixel Perfect start button allowing quick access to this feature.

PixelPerfect Start Button

And here is the final Pixel Perfect UI that you can open by clicking on the button above.

PixelPerfect UI

HAR export

Support for exporting HAR (the HTTP Archive format) from the Network panel is now a built-in feature and you don’t need an extension for it. All you need to do is select the Network panel (reload the page if necessary) and use two context menu actions:

  • Copy All As HAR: copy collected data into the clipboard.
  • Save All As HAR: save collected data into a file.

Exporting data from the Network panel is often automated (e.g. when testing web applications using Selenium). If you want to create a HAR file automatically for every loaded page you need to set the following preference (use about:config) to true:

devtools.netmonitor.har.enableAutoExportToFile

Some automated systems need more flexibility than just creating a HAR file after every page load. Sometimes you need to send data to a remote server, collect and export HAR between two specific user actions, etc. That’s why we’ve introduced a simple HARExportTrigger extension that improves automation by exporting HAR API into the page content. This allows you to use small script to trigger HAR at any time.

Here is an example script that gets HAR data from the Network panel:

var options = {
  token: "test",
  getData: true,
};

HAR.triggerExport(options).then(result => {
  console.log(result.data);
});

Using console.* APIs on the server

The Firebug community has implemented many extensions that allow developers to use console.* APIs on the (HTTP) server side, so you can see your backend logs right in the browser. This feature is now natively supported in Firefox and you don’t need to install an additional extension.

All you need to do is enable logs coming from the server inside the Console panel.

Server side logging

This feature supports an existing protocol (used in Chrome Logger) that sends logs through HTTP headers to the client. Logs are consequently displayed in the Console panel as if they had been generated by JavaScript on the page. There are many server-side libraries that provide the appropriate server side API in various languages (NodeJS, Ruby, Python, PHP, .NET, Java, etc.)

Here is an example of server side logging:

var chromelogger = require('chromelogger');
var http = require('http');
var server = http.createServer();

server.on('request', chromelogger.middleware);
server.on('request', function(req, res) {
  res.chrome.log('Hello from Node.js %s', process.version);
  res.end();
});

server.listen(7357);

And here is what the server-side log looks like in the Console panel:

Server log

Final words

As I mentioned at the beginning of the article, we are trying to unify native Firefox Developer tools (DevTools) and Firebug since we believe that this is an effective strategy for delivering great tools for web developers. There is more yet to come, but this post should give you an overview of our plan and where we are heading. Stay tuned!

Please post feedback in the Firebug group, thanks.

Jan ‘Honza’ Odvarko

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)