devtools.editor.component to orion in about:config.

… and then open a Scratchpad (with Shift-F4 or via the menu item in the Web Developer submenu).

Update! John via the comments mentioned that if you have already opened a Scratchpad, you will need to restart your browser for this change to take effect. Thanks for the note!

It’s currently disabled because there are some outstanding issues for RTL locales and some accessibility concerns. We hope to address those issues with upstream contributions wherever possible — Mihai’s an Orion contributor now. Eventually, this preference will become the default.

What do you get with this preference? Nice JavaScript syntax highlighting for starters. You also get other conveniences like bracket matching and (semi-)smart indentation.

This feature’s an important first-step towards making the Scratchpad a really comfortable editor for writing and testing bits of JavaScript. It gives us a solid foundation to add more interesting features to the Scratchpad in the future, and gives us a Source Editor component that we can drop into other elements.

There were a couple of fun things about doing this. One, all of the UI inspection was done with the built-in Inspector in Firefox. If you load up chrome://browser/content/browser.xul in a tab and invoke the inspector (after setting devtools.inspector.enabled to true in about:config and restarting), you can look at the various parts of the browser chrome.

To make the toolbar visible, you’ll probably have to select “View Bookmarks” from the bookmarks toolbar dropdown next to the search box in the UI. Even if it’s on, you’ll probably have to toggle it off and on again to get the bookmarks to show up.

Deselect the View Bookmarks Toolbar menu option and then re-enable it.

Once that’s done, open the Inspector (Cmd-Shift-I or from the Tools menu on a mac, Ctrl-Shift-I or the Web Developer submenu in the app menu on PC) and hover over the bookmarks toolbar in the browser.  Ultimately, you’ll want to highlight the toolbar element with id “PersonalToolbar” and take a look at its attributes. You’ll see that the mode attribute is set to “icons” by default.

Now for the magical part: Open the Web Console on this page (Cmd/Ctrl-shift-K). In the JS Input line, type:

$(“PersonalToolbar”).setAttribute(“mode”, “text”);

and hit Enter. The icons should disappear from the embedded browser document.

And that’s pretty much all there is to this addon. Check out the source on github or in hg, view some minimal documentation, and, when it gets approved, install it from AMO.

Open systems are better and lead to more productive coders. This is a wild assertion I’ll make with some cheek, mostly because I don’t think any exemplars from closed-system programming can really refute it, or will. Programmers who get into pure languages like Lisp and Smalltalk ramp up quickly and become more productive because they have full view of the system’s source code.

So too, the web.

Web-programming is often a cut and paste experience. I hear the term “cut-and-paste inheritance” used derogatorily too-often. While it’s true that in some cases, from a code-design perspective, just pasting blocks of code from one document to another can lead to a poorly-designed system, it is great for getting little pieces of code to work. It is the scientific method applied to programming. You see something that works in one place, you try copying it over and see what fails on your page. Continue.

One area where view-source breaks down is in the analysis of “what happens” with that source code. The Error Console in Firefox is a poor-excuse for a debugging mechanism and linked to the view-source window only by a hopefully connected error and a line number you can click on. Errors can come from any tab and are not necessarily associated with your code. There is no sense of iterative feedback. You have to hunt for it and usually fall into a pattern of clearing your console and reloading the page to see when the errors occur. This leads many developers to write their own logging function. Or when they’ve graduated to more advanced development, install Firebug which presents dynamic views of your source code in exciting (and sometimes surprising) ways.

Another mysterious failing of view-source is in a dynamically generated page. Something that uses document.write() or a bunch of appendChild() calls often doesn’t show correctly in view-source. A trick I learned recently to see these types of changes is to select some text and right click on it and “view-selection source”. Not exactly intuitive, but this will show you what your code generated.

I don’t think anyone can claim that view-source is a bad thing, though I have seen people try to get around it. Usually under the guise of “I have some important information or data that I need to protect”. I have seen people file bugs to add a mechanism to Firebug to prevent inspection of the underlying HTML on certain pages. I find these types of requests pretty funny, generally, and a little sad because people who think this way fundamentally don’t understand what the web is about and how it works and why it got to be the wonderful thing it is today.

It’s a fairly common practice to hide content behind a flash barrier to prevent people from getting their grubby paws on it. This creates a large swath of the web that you really have no ability to play with or learn from. Also, I think it’s fairly safe to say that learning to program in Flash is a more expensive proposition than learning to program for the web. You have to pay for tools, books and example code. If you want to make something that looks like this widget over here that has some wandering penguins on it, you have to figure it all out for yourself.

Alex mentions generative tools and libraries like GWT that create HTML and CSS styling as by-products of their execution and that these create a not-very useful rendition for view-source. This is true. Even PHP-generated HTML can be pretty disheartening to look at if you’re trying to figure out what’s going on in a web-page — its poor formatting and machine-generated constructs are not pretty to look at, but you can still sometimes glean some of the workings behind them. Having hacked around in WordPress for a few years, understanding the way the PHP code generates a blog’s output is an interesting experiment to puzzle through. I wouldn’t have been able to do that without view-source.

Anyway, I think I’ve burbled about this enough. I love view-source. There, I’ve said it. It is one of the most valuable tools we have for understanding and learning about the web.

We haven’t really nailed-down what it means to have these here yet, and as of this writing, the logging summaries aren’t being printed out so the information’s only semi-useful at-a-glance. We’ll get that fixed quickly though. Ultimately, I think failures on these boxes should be taken seriously and if you check in and see them turn orange, you should take a close look at the logs to see what happened.

Also, if you see any problems with these machines, please file a bug on it in core/testing. I’ll be watching that bucket with great vigilance.