On 23rd of April 2015, Mihai Șucan passed away due to metastatic cancer caused by RDEB.
My name is Mihai and I work on the Firefox developer tools. When it comes to web development, I like both server-side and client-side work. I am mainly interested in web browsers, web standards and related technologies.
24 March 2014, 17:01
Hello Mozillians!
This is just a quick note to the blog readers about a new page on MDN: How to customize the Firefox Web Console output. The API presented is fully available in the Aurora channel, and partially available in the beta release channel.
I hope add-on authors interested to extend the developer tools will find the documentation useful.
12 March 2014, 11:12
Hello Mozillians!
We are really close to the next Firefox release, which will happen next week. This is a rundown of Web Console changes in current Firefox release channels.
Here is a really nice introduction video for the Web Console, made by Will Bamberg:
You can learn more about the Web Console on Mozilla's Developer Network web site.
Added page reflow logging. Enable this in the "CSS > Log" menu option (bug 926371).
You can use the -jsconsole command line option when you start Firefox to automatically start the Browser Console (bug 860672).
Added split console: you can press Escape in any tool to quickly open the console (bug 862558).
Added support for console.assert() (bug 760193).
Added console.exception() as an alias for the
console.error() method (bug 922214).
Autocomplete for JavaScript input provides suggestions from the currently selected stackframe in the JS Debugger (bug 842682).
Added option to toggle the display of message timestamps in the console output (bug 722267).
Added a dark theme for the console output.
CSS warnings disabled by default (bug 909756).
Added the console API to Web Workers (bug 620935). Now you can log messages to the Web Console from Web Workers.
Pretty output for objects in the console output. You can now see previews of object properties, array elements, DOM elements, node lists, and more (bug 843004).
Compact object previews are also used in the object inspector, which is also used by the JS Debugger.
The changes made in bug 843004 also include new APIs that allow custom message output to the Web Console. You can customize output for different object types as well.
Nicer output for console.trace() - inline display of stack frames with syntax highlighting (bug 939783).
Now the input line is focused when you click anywhere in the console output (bug 960695).
Added cd() support. Now you can execute code in iframes/frames (bug 609872).
cd(someWindowObject) switch the JS evaluation scope to the given global window object - you can get it from
iframes using
iframeElement.contentWindow.
cd('.selector iframe') - for ease of use you can specify a CSS selector that matches the iframe you want
to use as eval scope.
cd(iframeDOMElement) - you can also point to the
<iframe> DOM element.
cd() with no arguments to reset eval scope to the top window.
Note that cd() is also available in Scratchpad.
Rich previews for objects (bug 584733): syntax highlighting, you can click on property values/array elements to inspect those objects directly, DOM node lists and more.
DOM elements are now highlighted in the page when you hover the DOM element in the console output (bug 757866). An inspector icon is also included - click it to jump to see the DOM element in the markup view.
Added support for pretty output of objects in the Browser Console as well (bug 952190).
Network requests are now logged when you connect to Firefox OS (bug 917227). This affects both the Web Console and Network Monitor tools.
Added console.count() (bug 922208).
Autocomplete for array members, so now you can type
myArray[2].foo to get suggestions (bug 943586).
Ctrl/Cmd-Shift-K no longer toggles the Web Console. To close the developer tools use Ctrl/Cmd-Shift-I or F12. Ctrl/Cmd-Shift-K is now used to focus the Web Console JS input if it is not already focused. See Rob's blog post for details and bug 612253 for the development notes.
The Browser Console no longer shows the JavaScript input by default (bug 922161). Set devtools.chrome.enabled to
true in about:config to get back the input.
JavaScript warnings and network logging are disabled by default (bug 966692).
Big thanks to all of the contributors who made patches to fix and improve the Web Console.
Next week we will start work for Firefox 31. If you are a developer I recommend you to use aurora or nightly builds to get the best of our devtools.
10 October 2012, 15:49
Hello world!
Here is a summary of the improvements we have made to the Web Console in the latest versions of Firefox. In the new Firefox 16 release we have added the ability to display Content Security Policy warnings and errors. We are also highlighting network requests that happen over HTTP on HTTPS pages (and vice-versa), and we did more output performance fine-tuning.
In the new Firefox Beta we have moved the Web Console UI into its own <iframe> - which
gives us better flexibility for upcoming work we will do. We changed the UI to match the developer tools theme and we made
objects you pass to console.log() inspectable. For example, if you call
console.log(document) you can click [object HTMLDocument] to inspect it. JavaScript input autocomplete
also received a number of improvements. Last, but not least, now you can zoom in/out the text in the Web Console - just
press
Ctrl-- / Ctrl-+. The default font size should also match your system's font size settings.
In the new Firefox Aurora release we landed a big chunk of work that makes the Web Console remotable - we now make use of the Remote Debugging Protocol. This means you will be soon able to connect Web Console instances to your B2G, Fennec or other Firefox for desktop browser instances. We currently lack UI to allow you to do this, but we are working on it. This work also paves the way to a Global Console that could replace the Error Console, some day.
At the end of September the developer tools team had a meetup in London. There I had the chance to demo the Web Console client connected to a B2G server:
In the above screenshot you can see the Web Console client running in a local Firefox for desktop build while connected to a local build of B2G Desktop running Gaia. You can see network logging, object inspection, network request/response information and script errors coming from B2G.
To learn more about the Web Console remoting capabilities see bug 768096 and the wiki page on MDN. To follow the progress with B2G integration see bug 795691.
What is next? We are going to complete work on B2G integration, improve the way Web Console output works, and we will probably add a Global Console. We also plan to improve the user experience of the object inspector and the network panel.
6 June 2012, 10:35
Hello Mozillians!
For the Aurora update that's happening this week we have some major changes under the hood for the Web Console.
Work on making the Web Console UI async, decoupled from all the error and network listeners, started in July last year (bug 673148). Even if it took almost one year to get this bug fixed, I worked on these patches for about 3 months (loosely summing up the total days of work spent on this specific bug).
Back in those months we strongly pushed for various developer tools to land and get enabled by default in Firefox. I've been working a lot on the source editor which was needed for the Style Editor, the JS debugger and Scratchpad. Work on the Web Console was on and off.
There was modest to good progress for the Web Console async work until around September - October when Mozilla's electrolysis project was re-prioritized. The initial work on the patch started out with the goal of making the Web Console ready for e10s. When priorities changed, I went back to source editor work which was higher priority at that point.
In January - February a really brave and courageous contributor, Sonny Piers, took the huge patch and rebased it. His efforts were commendable given the size and complexity of the work that was going on. Thank you Sonny!
In March I resumed work and I strongly focused on completing the async patches. Last week the last patch landed in the nightly builds of Firefox.
What changed? Most of the Web Console was implemented in a single file, HUDService.jsm.
It had everything - from UI code to all the error and network listeners and stuff for the window.console API.
We have now broken that code into separate scripts with the goal to leave
HUDService.jsm as the script that implements only the UI. The new HUDService-content.js script
implements all the listeners, all the "backend stuff". The UI code must no longer directly access the content window and
objects from the content document.
Why? This work allows us to move to the remote debug protocol and to have the Web Console UI connect to your Firefox Mobile or B2G device where all the error and network listeners are instanced. This work paves the way to a remotable Web Console.
The added benefit is that the async-ness had some modest performance benefits to content scripts (pages) that used the
window.console API - a call to any method no longer had to wait for the Web Console UI parts to update.
In the future other Firefox components and extensions can build different UIs on top of the data collected by the
HUDService-content.js script.
Lessons learned:
Thanks go to Rob Campbell, Dave Camp, Felipe Gomez, Ms2ger, Joe Walker, Sonny Piers and everyone else who contributed to getting these patches to be ready to land.
Building on top of the async Web Console work we've also made some really nice output performance improvements (bug 722685). In bug 746869 Boris Zbarsky analyzed the performance issues in our code and he made a number of valuable suggestions on how we can make it faster. Thank you Boris!
Our first attempt to make the Web Console output faster has landed in Firefox. Let's go straight for the numbers:
Opera 12 (post-beta, latest snapshot, with "cutting-edge" Dragonfly):
Closed console:
Open console:
Display performance is sufficiently good. However, it becomes slow to very slow after several runs. No message pruning happens.
Chromium 18 (beta):
Closed console:
Open console:
Performance in content pages is very good. However, display performance is actually poor. First run is fast. Subsequent runs take far more. The web inspector tool UI is frozen for many seconds when the second and third runs happen. Content process separation helps a lot. Even if Web Inspector's display is frozen, web pages continue to run smoothly.
Firefox 13 (without the async patches):
Closed console:
Open console:
Firefox locks up badly, turns gray (frozen). Subsequent runs take the same amount of time - not slower. We prune old messages.
Firefox 15 nightly (with the async patches landed):
Closed console:
Open console:
Firefox freezes for less time, it doesn't turn gray on Ubuntu and content script impact is reduced. Subsequent runs are not slower.
Firefox 15 Aurora (with the performance patch landed):
Closed console:
Open console:
For comparison: do note that 1000 dump() calls take around 10-20 ms in Firefox. (dump() is a dumb method we use to output messages to STDOUT.)
Having the Web Console open or closed no longer directly impacts console API calls. Now the UI no longer freezes and results show up quickly.
I tried with 5000 calls and we now do better than Opera's Dragonfly and Chrome's Web Inspector - in terms of UI updates. Still, console API calls finish faster, for some reason, in those two browsers.
Please do note that I used the simple test attached to bug 722685 for testing. These numbers are not meant to be "scientific" or anything like that - they are based on my machine setup.
We will continue to do further work in improving the output performance (bug 761257). At this point we still need to avoid doing some unneeded work when a lot of messages end up in the queue to be displayed. We also need to better balance how often and how many messages we display during "heavy fire" - during the execution of content scripts that invoke the console API methods many, many times for an extended period of time.
We have plans to move the Web Console UI into its own
<iframe>, change the UI to match the other developer tools theme, add the option to move the UI
into a real window, make a global console that could replace the Error Console and, obviously, switch to the remote
debug protocol so you can use the Web Console with remote Firefox instances. All this and many other improvements, of
course!
You may wonder "when?" and the answer to that is that all the improvements will come gradually when we get to implement them.
File bugs, find regressions and let us know what you like and dislike! Thank you!
13 March 2012, 12:40
Hello everyone!
This week we will make the merges for new Aurora, beta and stable releases. This is always great news for us: we get more of the stuff we worked on released to our users.
In the new Firefox stable release (version 11) we have important performance improvements for handling very long lines in the source editor, fixes for CSS syntax highlighting and more. For example, users on Linux can now select text to copy to the primary X11 buffers and they can middle click to paste.
The new Firefox beta release (version 12) adds support for find (Ctrl-F) and jump to line (Ctrl-J), including other smaller fixes.
The new Aurora release (Firefox 13 alpha). This release marks important changes and it includes a number of patches from awesome contributors! The list:
<textarea> fallback. We now only support the Orion-based source editor (blog post by Rob).
Our awesome contributors did:
mousedown/mousemove/mouseup
events. This is going to be used by the JS Debugger.
Thanks to all the contributors for their awesome work!
Other exciting news: Eric Shepherd, the "documentation overlord", is writing the source editor documentation. For now the wiki page is a work in progress, but the results are already looking great! Eric will also write a guide on how to use the source editor. Thank you Eric!
We hope you like the work we are doing! Comments, suggestions for improvements and patches are always welcome!
1 February 2012, 13:13
Aloha!
Mozilla has made the final release of Firefox 10. The developer tools team has worked for over 18 months for what you get to play with - this new release brings a lot of the hard work each team member has put into these tools. I am happy to be one of the people who contributed to this really big release. We always strive for quality and performance. While these tools are now undergoing a lot of work in terms of features and polish, they are already at a point where we can be proud of them.
The Eclipse Orion code editor has gone through great improvements since Firefox 8 and it is now enabled by default. Collaboration with the Orion team has been very successful and we are making great progress. I really enjoy working with them!
Firefox 11 beta features a new Style Editor developer tool that also uses the Orion editor for syntax highlighting. We are also working on a JavaScript debugger for a later Firefox release which is going to use the same editor, with additional features.
Keep your Firefox updated and have fun using our developer tools!
12 August 2011, 19:15
Hello world!
Just a quick note: today we have landed the Orion editor in Firefox. If all things go well, users will play with Orion in the new Scratchpad developer tool in Firefox 8.
Implementation and integration notes: only the Orion TextView is used and for now this feature is disabled by default due to some bugs with bidirectional text support and accessibility issues. We are looking into improving the code so we can later enable Orion by default. This will happen after Firefox 8.
To enable Orion you need to go to about:config and change
devtools.editor.component to "orion".
An obligatory screen shot and screen cast:
I did the screen cast one month ago. The only changes since then are code quality improvements, bug fixes and minor UI improvements.
Big thanks go to the awesome Orion team for their great project and fruitful collaboration, and to the Mozilla colleagues who had the patience to review all the code I wrote: Robert Campbell, Gavin Sharp and Ehsan Akhgari.
Have fun! Play with tomorrow's Firefox nightly builds or... wait for the Firefox 8 alpha/beta/stable release (whichever you prefer).
If you want gory technical details, just check out the bug reports where all the work was done: bug 636727 and bug 660784.
22 March 2011, 14:00
Hello everyone!
It is a long time since I last wrote anything in this blog, but today I have a great occasion to write about! Today I am really glad to be part of a great open source project release: the new Firefox 4 from Mozilla is out! Go ahead, download the browser, play with it and use it!
Since July 2010 I have started to work with the new developer tools team. This is the awesome team that brings you the new Web Console tool into Firefox 4. :)
There's a special feeling to making contributions to such big projects that reach hundreds of millions of people. These months I learned a lot of cool technical stuff from the fellow software enthusiasts at Mozilla. I also learned that open source at Mozilla goes beyond putting the Firefox source code on a Mercurial repository, out in the open for everyone. Open source is the way to drive development, manage a project and a company.
Congratulations to the whole Mozilla community for this awesome release!
Update: Yesterday, on the Firefox 4 release day, I found a blog post from a fellow Mozillian titled Proud. I really liked the video he linked. Here it is:
12 March 2010, 16:57
Hello everyone!
In the latest article I wrote about SVG and Canvas I included a small HTML5 demo which renders a color histogram using Canvas, analyzing any image element. Knowing that the Canvas API allows developers to also read video frames, I wanted to test how fast can JavaScript and Canvas render a color histogram while the video plays.
I changed the initial script so that now it works with HTML5 videos. Here is the result:
In this demo I include a small video and a big HD trailer - just out of curiosity I wanted to see something that barely runs within the browser. The demo works with Opera 10.5 and Firefox 3.6 - tested on Linux and Windows. Currently, Chromium 5 on Linux crashes when I try to load the page.
I did spend quite some time testing various improvements to the performance of the script. I would note that changing the script to not access the DOM elements and properties directly, does not bring any important improvements in execution speed. However, the change to use bitwise operations did make a difference. Further improvements would come if I would inline functions and remove some of the options. Still, any ideas on how to further improve the performance of the demo would be welcome.
Working on this HTML5 demo I also explored a new API available in Firefox 3.5: Web Workers. As I expected, the result of adding a web worker to this use-case is not something I am happy with. In a web worker I cannot access the video, nor can I access any of the canvas elements. I could move only a really small part of the code into a worker, and the performance penalty of sending the pixels in a message from the main thread to the worker thread is too significant. In the end, it runs quite slower than the script which does not use any web worker.
26th of June update: Opera 10.6 beta 1 was released a few days ago. This release brings support for Web Workers and it is really great to see that my Web Workers demo works in Opera as well.
Any feedback is appreciated.
4 November 2005, 09:28
Hello!
Yesterday I had to install Windows 98 on a really slow computer by "today's standards", a Pentium I, with only 32 MB.
The computer is a bit unstable. During system installation had some BSODs (probably corrupted RAM and/or damaged mother board).
This guy will have a broadband Internet connection.
As a browser, I, of course, excluded Internet Explorer as an option.
I got Opera 8.5 with all settings to the minimum (no skin, no smooth zoom, no smooth scrolling, no special effects, nothing). Booted and worked really fast, loved it ;). I wasn't expecting that. Yet, it causes BSODs on Opera's own site and some other sites (told you the computer is unstable!).
Now, I had to give Firefox 1.0 a try, hoping it's not slower and won't cause as many BSODs as Opera.
Yet, yesterday I finally saw for the first time the true speed difference in start-up times between Opera and Firefox. Starting Opera takes less than 3 seconds ... yet with Firefox ... you wait and wait more :), from double to triple more time. Page rendering, scrolling and overall browser usage is also slower (menus, preferences, etc).
Sadly, there's nothing to configure in Firefox to really make it faster. Also, Firefox crashed on few starts and on some sites (like mine).
Conclusions:
The only problem of Opera is PNG rendering. On my site Firefox was a tad faster :).
I actually managed to browse my site with Opera ... but Firefox crashed :).
P.S. This is not an "Opera fan rant". It's clear to me now which browser is faster: Opera. Those who really want to know which browser is faster got to try them with a really slow computer.