~robcee/ more than just sandwiches

Posted
10 September 2010 @ 10am

Tagged
Code, Firefox, Mozilla

Inspector and Error Console disabled, preferences, backouts

Last night I checked in two patches to disable the Inspector and the Error Console in Firefox 4. If you’d like to turn them back on, the code is still there. In about:config, change devtools.inspector.enabled or devtools.errorconsole.enabled to true. (note: you will need to restart your browser for these changes to take effect. It checks at startup time only.)

Bugs are: Inspector bug, and Error console bug.

It is disappointing that we won’t be able to land all of the features we wanted for the Inspector in Firefox 4, but it was the right decision to make. Given the number of outstanding bugs and some widget-related problems, there was no telling how many additional bugs would be discovered during the run up to final release. Making that decision now allows us to focus on shoring up the Web Console so it’s the best feature it can be in the time remaining, and it is coming together quite nicely thanks to everybody’s efforts.

Also, between the two features, the Web Console is the one that will most-likely affect web-site developers the most. It’s defining a window.console object if none already exists on a site, allowing printf style debugging from code. It shows network request details and allows object inspection. The JS command-line evaluation is quite decent.

Soon (like, when some of this Firefox 4 beta madness dies down), we’ll be spinning up a devtools branch where we can do some of this work in a less scattered environment than bugzilla. One of the difficulties we’ve had with the Inspector were some of the bounces due to test failures and performance regressions. Landing code on mozilla-central can be very difficult. We tested some of the larger pieces on try server, but subtle performance changes can be really hard to spot there. Review bandwidth is limited and precious, so when we’d get our R+, it was usually a scramble to get our patch in to free up the downstream code from further rebasing.

Bounces suck for many reasons. I am extremely conscious of the impact on developers when I have to backout a patch. I’m hoping a separate development repository with all the trimmings can alleviate that, though there are no Magic Bullets™.

One upside(??) is that I’ve gotten pretty good at backing out patches with Mercurial!

hg diff -r last-change:first-change-parent >../backout.patch
hg qimport ../backout.patch –push
hg qrefresh -m “some decent backout message”
hg qfinish -a
hg push…

I picked this up from a discussion with Gavin and Vlad in IRC during one botched checkin. The nice thing about this method is that there’s no merge required. See also, Ehsan’s recent post on the topic.


10 Comments

Posted by
Ehsan Akhgari
10 September 2010 @ 3pm

About the backout tip, this won’t work correctly for things like renames, unless you use git-style diffs. Also, avoiding the merge would mean that there might be conflicts which you would need to resolve by hand…


Posted by
robcee
10 September 2010 @ 4pm

Good points. I do have git = 1 in my .hgrc’s [diff] section so I should be good there. Thanks, Ehsan!


Posted by
Alfred Kayser
10 September 2010 @ 8pm

Beta madness indeed. On average 5 patches per day with impact on themes, of which at least 1 per day is backed out later. And for most theme changes, followup changes revert some of the changes. Changes, Changes, Changes, …


Posted by
Havvy
12 September 2010 @ 5am

If it is possible, I would make those five commands into one typed command. (Just saying)


Posted by
robcee
12 September 2010 @ 6pm

add semi-colons to taste.


[...] 4.0 přinese řadu novinek, kterých si povšimnete i u nástrojů pro vývojáře. Asi tou hlavní je nahrazení Chybové konzole novou Webovou konzolí, kterou naleznete v nabídce [...]


Posted by
Dan Mosedale
14 September 2010 @ 4pm

Do nsIConsoleService messages show up in the web console? If not, is the only way to see them to re-enable the old console?

Thanks


Posted by
ddahl
14 September 2010 @ 4pm

@dmose

We do show nsIConsoleMessages – after we determine they originated in a specific tab’s contentWindow.


Posted by
Dan Mosedale
14 September 2010 @ 5pm

@ddahl, ah, interesting. So presumably some of them will never be shown if they didn’t originally come from a contentWindow. And for those, the only way to see them would be to re-enable the old console?

@robcee if it’s straightforward, it’d be nice if your blog could email folks about responses to comments in blog posts. If not, c’est la vie. :-)


[...] bugs would be discovered during the run up to final release,” explained Mozilla developer Rob Campbell last Friday about the decision to pull [...]