Just a quick note to let people know that I’ve updated the Workspace extension recently. Added support for saving and loading files as well as a hotkey (F4) to open it from the browser.
Many thanks to Erik Vold for some nice fixes and improvements!
Install it here: http://antennasoft.net/addons/workspace.xpi.
Sometime early this week, we disabled the pinch-zoom controls on trackpads in OS X (and maybe elsewhere, I’m unclear on how well-supported these gestures are on other platforms, but certainly present on mobile). You can read the gory details over in bug 613909.
I use pinch-zoom All the Time. It’s a feature I can’t live without. Especially as I’ve gotten more used to doing similar actions on multitouch tablets and smart phones, the gesture feels natural to me. When in full screen mode, it makes sense to be able to resize the page to fit the ridiculous dimensions of my monitor.
Enter Pinchy!
It’s a pretty simple add-on (built on the add-on sdk) that turns on some of the disabled preferences. Once you’ve installed it and it’s run, you can safely remove it or disable it from the Add-ons Manager.
You can accomplish the same thing either through about:config or by editing your prefs.js file in your profile directory. The prefs I’ve included are:
user_pref("browser.gesture.pinch.in", "cmd_fullZoomReduce"); // zoom -
user_pref("browser.gesture.pinch.in.shift", "cmd_close"); // close tab
user_pref("browser.gesture.pinch.out", "cmd_fullZoomEnlarge"); // zoom +
user_pref("browser.gesture.pinch.out.shift", "View:FullScreen"); // toggle full screen
user_pref("browser.gesture.pinch.threshold", 66);
user_pref("browser.gesture.swipe.left.shift", "Browser:PrevTab"); // prev tab
user_pref("browser.gesture.swipe.right.shift", "Browser:NextTab"); // next tab
the Shift+Pinch in to close tab is particularly sweet. Also liking Shift+swipe to switch tabs. I have my prefs already set to go to the top of page and bottom of page on swipe and if there’s any demand, I can add those prefs in as well.
If only it were this easy to customize these gestures in every app.
Kudos to http://t.tal.by/post/95428783/changing-firefox-gestures for the handy list of preferences (circa Firefox 3.1!).
This weekend, I did a bit more work on the Workspace to get it closer to a releasable state. I also had some help in the form of some community contribution via the prolific Erik Vold on github.
Download: workspace.xpi
* added the relevant .htaccess bits so you can install directly from the link. Just click Allow. It’ll be ok, I promise!
New Features
Todo:
I think once we have those we can put it on AMO. Feedback and feature requests welcomed! Code moreso.
I went looking through my library for the classic Smalltalk-80 books to lookup the definition for the original consoleworkspace. When I realized I didn’t have the “orange book” on my shelf, I searched for it and found all of the original Smalltalk-80 books in PDF: http://www.world.st/books.
From Smalltalk-80: The Interactive Programming Environment (p. 106, How to Evaluate Expressions):
It is common practice to keep around a workspace in which to type expressions that can be selected and evaluated, or from which to select previously typed expressions. Whenever you want to reevaluate an ex- pression evaluated earlier, simply select the appropriate text in the workspace and choose the yellow button command do it.
You may of course edit some of the existing text before you select and evaluate it. In a sense, text left in workspaces form templates for commands.
I’m going to finish adding a couple of features to the Workspace addon then I’ll push it to AMO. After that, we’ll likely convert it to the Addon-SDK as part of our initial devtools widgets.
One feature I wanted in Firefox 4 was a JavaScript Workspace. I know I’ve talked about it to a bunch of people. Most of the time, people looked at me like I had a chicken on my head. The concept is so simple yet hard to really convey how useful it is.
Conversations inevitably go something like, “The Console already has a command line, isn’t that good enough?”
“Well, it’s great, but a Workspace lets you write out code as you think of it and it just stays there. You don’t have to go digging through history in case you want to copy and paste it elsewhere.”
more staring as if I had a chicken on my head followed by an incomprehensible, hand-wavey discussion about what you could do with them in Smalltalk…
Anyway, I decided to create a little add-on to better illustrate the idea. It’s pretty rough right now. It has a status bar that doesn’t do anything, and it doesn’t have nice menus to let you save and load files into it. But it has all the keyboard shortcuts you’d expect in an editor (cut/copy/paste) and a context menu that lets you Execute, Inspect or Print selected code against the currently active browser tab’s content. You can open one from the Tools menu (I know, I know, I need to add an entry to the developer menu in the Firefox menu. It’s a prototype!)
Try it out, let me know what you think.
Download: http://antennasoft.net/addons/workspace.xpi
Source: https://github.com/robcee/workspace
Every year we bring in Mozillians from around the globe to have a focused get-together. It’s a time when we can do some heavy planning, and brainstorm in one place. Often, some of the hallway conversations and parties generate good ideas.
One conversation I had last night with Dietrich, Dolske and Mak was, how do we get new contributors up to speed on how to hack Firefox? We’ve already got a ton of excellent documentation on MDN for first-timers and seasoned veterans, but what most people really need is MXR and HG.
Setup some keyword searches:
Now when you want to look up a reference or definition, type “mxr {search-term}” and it’ll return your search results. If you want to search for a file, say, browser.js, type “mx browser.js” and you’ll see the results. (Hint, the one you want is at the bottom of the page)
Got any other suggestions or hacks? Add ‘em in the comments!
An Extension
A couple of years ago, I wrote an extension to take a list of tabs in a window and generate a page with some easily copyable links in it. I neglected the extension and let it moulder until a triage meeting the other day and wanted to get a hunk of bug links out of my browser.
Well moulder no more!
I bring you a reinvigorated WikifyTabs with support for Wiki links, BBCode and HTML. Check it out, browse the source, make some improvements!
For years, the world has been able to rely on Firebug and its console for debugging web sites. It has been a convenient and productive tool and we’d probably still be languishing in the window.dump() mines without it. A side-effect of this availability has made some patterns appear that don’t play nicely with consoles that aren’t implemented exactly the same way as Firebug’s console object. We’re running into a few of them now that Firefox has gained its own console object.
Here’s a not-terribly hypothetical situation you might imagine. You’re a web-developer working for a small company. You’ve got a website. You want to do some debugging on your front-end scripts. Naturally, since you have Firebug installed, the first thing you do is drop a few of these around your code:
console.log("I am here!");
Simple, effective, printf-style debugging. Then you decide you want to show your manager what you’ve done on her own computer. You point her to the address and she loads it up and says, “this is broken. I don’t have Firebug installed so I’m getting exceptions calling console.log().”
Pwnd! You throw in a check that might look like this:
if (window.console) {
// set a variable, do some stuff, maybe write
// your own log() wrapper...
Problem solved!
Maybe then, you start getting fancy and add a timer to your new logging function.
function myLogFunction(method, message) {
console.time(method.toString());
var result = method();
console.timeEnd(method.toString());
console.log(message, result);
}
Neat-O! Except, console.time() isn’t a function in some browsers and now won’t work properly.
One possibility is to check explicitly for Firebug by expanding your first window.console check like this:
if (window.console && window.console.firebug) {
That’s become a fairly standard pattern, though I believe it’ll exclude Chrome, Safari and Opera from your debugging efforts.
A better way is to test for each function you want to use:
if ("console" in window && "time" in window.console)
// define your method
This has the benefit of not coding for one particular type of debugging tool, will allow for graceful fallback in the event that your feature is not defined and allow you to tailor your debugging around different feature sets. This is the way libraries like jQuery check for browser capabilities and you should too. You want your website to work everywhere, don’t you?
An even better way around this would be to not ship your debugging code in a production web-site, but you may have good reasons to ignore this advice.
It’s Black Friday! For some of you, that means lots of shopping, post-turkey discomfort and watching football. Maybe all at once. For me, it meant checking out the latest development trunk of the Add-ons SDK (née Jetpack) and bundling up an add-on.
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.
A few years ago, back in the heady days of 2006, dria and I were sitting around discussing alternative browser designs. One of them was dislodged from my memory a few days ago when Labs announced the Chromeless project. How could we make use of all the vertical real-estate on a widescreen monitor? One idea was to use a panel-based browser which is now technically feasible with the addition of the xul <panel> element.
In this mockup, all of the controls have been moved into separate panels. A navigation toolbox contains the back/forward buttons, reload and a home button (configurable like the current toolbars). A tab panel contains vertically-arranged tabs with the title and favicon or a film-strip-styled tab-preview à la Fennec. To the right is a Bookmarks panel showing available bookmarks. A small add-ons panel at the bottom contains buttons for various add-ons the user has added.
The document area contains a single browser view. Above it, a draggable, dockable location bar sits. Somewhere, there is probably a search panel with the user’s selected search engine. Other missing fixtures are an auto-hideable menu bar for Windows and Linux. A panel for the Bookmarks toolbar (just the buttons, without the full bookmarks view) would also be a useful feature. There would be others like History too.
For this to work, we’ll need a few more of the planned features for panels: Dockability, hideability (slide them off screen when not in use), and better positioning smarts. When the document view is full-screen, the panels should get out of the way at the screen edges and only zoom in when the user hovers over an edge with the pointer.
I think there are some interesting implications with a design like this, both positive and negative. Rather than burden you with my thoughts, I’d like to hear from others. What works in a design like this? What doesn’t?
Hit me!
We’ve been recently discussing some of the future directions for our Devtools group within Firefox world. One of the proposals is to do some development on Github using Jetpacks for feature work. The idea being, we can work rapidly on these features in a collaborative, social space, and then fold them back in as a set of integrated features into the browser.
There are some funky implications with this. We’ll have to create a set of APIs for Jetpack to use to allow for the creation of a rich set of development tools. These APIs will likely be in Firefox/Gecko itself, and as such, will live in mozilla-central. I take this as axiomatic and non-negotiable, though the APIs themselves can certainly be augmented by other add-ons.
To “git” to the point, my questions are around the use of an external source repository for working on code that may at some point be re-integrated back into mozilla-central and Firefox. Right now, we’ve got precious little experience doing this and I’m trying to get a handle on some of the processes this might involve.
A few random thoughts and questions:
Quite possibly, a lot of these bullets are just not that important. A couple of them are, like revision history and the question about pull requests. It would be unfortunate if upon inclusion into mozilla-central, if we just lost all of the code’s original revision history. We could use a tool like hg-git to pull in the whole thing, but this could cause pollution in m-c.
Pull requests are a stickier issue. When something gets accepted into our code, do we require a committer’s form? How do we know the code is “safe”?
And then there are the potentially scary issues of downstream contributions. Code gets checked into mozilla, code is updated on github. Something is added to the github version later on and then we want to pull that back into m-c. Do we have to pull in all subsequent revisions? What about forked code?
It’s quite possible, I am worrying too much and none of these are actual issues. When it comes to Mercurial vs. Git, I think the differences are small enough that which one we use is irrelevant. I’m more interested in potential work-flow or procedural gotchas that could make our lives difficult. That also includes “social noise” from active Github users. Is the task of maintaining our code there going to outweigh the benefits of it?
and on and on… Please: Help me out here. Drop a comment or leave a note on the newsgroups explaining why I’m being paranoid and should just get over it and start pushing code to github.
Pages
Recent
© ~robcee/. Powered by WordPress using the DePo Clean Theme.
