Archive for the 'Firefox' Category

I recently started blocking ads in my browser. I don’t actually mind advertising, and I resisted blocking ads for a long time. I understand that some sites rely on ad revenue to earn a living, and I’m fine with that.

Why, then, have I started blocking ads?

Simple. Companies that insist on using tricks to try to force you to look at ads you don’t want to see. Pop-up and pop-under ads, for example.

Worse, to me, is those ads that pop up if you simply mouse over text in the middle of a news story. This is the epitome of skanky behavior on the part of advertisers. It’s offensive and disruptive. This is why I block ads now. If advertisers would simply realize, “Hey, if we only put some ads here and there in the main page and refrain from making them stunningly distracting, from interfering with the actual usability of the site,” then I would be perfectly happy to turn off the ad blockers and let the ads back into my life.

Until then, I’ll block the ads.

Current Firefox nightlies have support for the bleeding-edge CSS transitions specification. I’ve spent the last few days playing with this feature, and have written some examples as well as reference and how-to documentation for using them.

CSS transitions make it easy to smoothly animate changes to CSS styles, instead of changes taking effect instantly. With a number of ways to control and customize the transition effect, and support for everything from font size and style to colors and even position, you can create some impressive effects with very little work. I suggest taking a look at the demos I put together to get a good idea what you can do.

Obviously since CSS transitions are still in the Working Draft stage, it’s entirely possible the syntax could change, but this is a great way to easily add a little pizazz to your web content.

I’ve spent the last week and a half or so writing about WebGL, the in-progress specification to bring real-time 3D graphics to the web. This is a very, very cool technology done — in my opinion — in the right way: instead of inventing a whole new API, WebGL takes the established and well-regarded OpenGL ES standard and makes it available to web content.

I’ve written a series of eight articles with corresponding demos. In order to try them out, you’ll need to be running a trunk build of Firefox, and set the webgl.enabled_for_all_sites preference to true.

Getting started with WebGL

How to set up a WebGL context.

Adding 2D content to a WebGL context

How to render simple flat shapes using WebGL.

Using shaders to apply color in WebGL

Demonstrates how to add color to shapes using shaders.

Animating objects with WebGL

Shows how to rotate and translate objects to create simple animations.

Creating 3D objects using WebGL

Shows how to create and animate a 3D object (in this case, a cube).

Using textures in WebGL

Demonstrates how to map textures onto the faces of an object.

Lighting in WebGL

How to simulate lighting effects in your WebGL context.

Animating textures in WebGL

Shows how to animate textures; in this case, by mapping an Ogg video onto the faces of a rotating cube.

I should note that the last demo currently badly leaks memory due to a bug in the WebGL code in the current trunk builds of Firefox. A fix is in the works and should hit the tree soon.

I really look forward to seeing some of the excellent stuff that’s likely to come with the introduction of GL support for the web.

Happy the gerbil was running around in his exercise ball tonight, when she hopped from the tile to the slightly lower wood floor in the living room, and the lid popped off his ball.

Before we knew it, Happy was on the move, exploring the living room. I got down on my knees and tried to catch him, but of course he was too quick for me. So I got some food and put it out, and he ignored it, and started checking out under the couch, over by my chair, and so on.

So then I tried putting some food in my hand and waited, and while he came and sniffed around my hand a bit, he didn’t climb onto it, so I wasn’t really able to snag him.

Finally, I had a brainstorm. We just got Happy a new, larger cage the other day, and the old one (also glass) hasn’t been put away yet, so I had Sarah go get that while I kept an eye on Happy.

She brought it to me, still empty, and I set it down on its side on the floor, then placed inside it Happy’s food dish with a little food in it. Then we waited.

It only took a minute or so for Happy to notice it, sniff around a bit, then crawl inside. A quick tipping up, and Happy was recaptured and transferred back into his new cage.

Watching Happy explore the world while dodging my attempts to grab him was actually sort of fun. But in reflection, it also makes me think about how tricky it can be to document moving targets like the open Web. Stuff changes, and it changes fast — sometimes so fast you can’t keep up. Seems like every time you reach out to start writing about something, it either changes or gets made obsolete by something newer, better, or faster.

But, just like trying to catch a runaway rodent, documenting the open web is a lot of fun, in a strange, giddy sort of way.

I’ve just finished writing the documentation for the new device orientation support added in Gecko 1.9.2 (Firefox 3.6).  For starters, DOM windows can now receive MozOrientation events.

There are several new interfaces, as well:

• nsIDOMOrientationEvent
• nsIAccelerationListener
• nsIAcceleration
• nsIAccelerometer

I’ve asked for feedback and technical review from dougt among others, so it’s possible this material could change as I receive corrections, but based on my reviews of code, samples, and existing material, this should be fairly accurate.

This is going to be a very cool technology. Obviously it’s especially useful for mobile users, but laptop users may get some use out of it as well. It has a lot of potential both for user experience improvements (such as rotating the user interface based on the orientation of a mobile device) and for web gaming.

I’ve been busily working my way through the stuff that needs documenting for Firefox 3.6. I just finished adding material covering lightweight themes, including minor updates to the XUL window documentation. For now, this documentation largely defers to the lovely existing material on the Personas site.

I’m also working on the documentation for device orientation. This is coming along but isn’t ready for consumption yet, as I’ve had some questions. I’ve now got the answers, just need to integrate that insight into the material and finish working on it. I expect to have this documentation finished tomorrow.

Documenting Firefox 3.6 has been a very pleasant experience so far. Coders are doing a great job of keeping me apprised of what’s going on, and most of the work to do is either small or fascinating. That’s my idea of a great, great release!

Work continues (gradually) on documenting Firefox 3.6 for developers. I’ve just added information about an improvement to how add-ons can provide icons for display in the add-on manager.

In addition, the mozImageSmoothingEnabled property that’s been added to the canvas element is now documented. Looking at our canvas documentation, I realize we need a more traditional HTML element reference document added for canvas, and I hope to get to that before long, but in the meantime, I’m a little preoccupied just getting the Firefox 3.6/Gecko 1.9.2 stuff done in our current framework of content, so please bear with me!

I’m also continuing to triage various bugs, weeding out a few that don’t actually need documentation changes after all (my initial triage pass was very generous, erring on the side of assuming stuff would require doc changes).

I’m making good headway and feel pretty confident that we’ll once again have complete documentation in advance of shipping Firefox 3.6.

I’m starting to get gradually more productive again as I work toward recovering from pneumonia. Here’s a look at the stuff I’ve been up to.

I’ve continued to triage the bugs that are marked dev-doc-needed in Bugzilla; some of these, which I tagged myself, don’t actually correspond to things needing documentation, but instead were things I needed to investigate.

I documented the nsIScreen and nsIScreenManager interfaces today. This happened because of a minor Windows-only change to nsIScreen, in which it now reports 24 bits per pixel instead of 32 bits per pixel, since 24 bits per pixel is more accurate for the interface’s purposes. But these interfaces hadn’t been documented yet, and are small, so I figured I’d go ahead and write them up in their entirety while I was at it.

I started work on the SVG animation documentation, but found out shortly after starting work on it that SVG animation has been bumped to Gecko 1.9.3, so that’s on hold for now while I focus on stuff for Gecko 1.9.2.

I’ve added a new article, Updating themes for Firefox 3.6, to which we’ll add any information about theme-related changes in Gecko 1.9.2 and Firefox 3.6. So far I’ve added what I’m presently aware of to this, but if you know something I don’t, please feel free to update it!

Because the developer tools on Mac OS X 10.6 default to building for 64-bit now, there are a few changes you have to make in order to build Mozilla on Mac OS X 10.6. Josh Aas wrote a very helpful blog post a few days ago about this.

I followed his instructions and successfully built Namoroka on my Mac at home, so I revised the Mac OS X build prerequisites article to explain how to configure things to successfully compile a 32-bit Intel build of Mozilla on Mac OS X 10.6. It also still explains how to do it on previous versions of Mac OS X.

Hopefully this added information will help you get going!

In related news, progress is being made on building Firefox as a 64-bit binary; the guys working on it are estimating it’ll be running within a month or so. I look forward to seeing it in action!

If you’re working on Gecko, or Firefox, or Thunderbird, or really anything in the Mozilla universe that may impact developer documentation, there are a couple of things you can do to ensure that the relevant changes to developer documentation take place.

I mention this periodically in several forums, but it can’t be said often enough, so here we go:

First, if there’s a bug related to your work, make sure the “dev-doc-needed” keyword is added to the bug in Bugzilla. It doesn’t matter if you’ve actually made the change or not. The writers only apply changes to the documentation once the bug is both tagged as “dev-doc-needed” and the bug is marked as fixed. Until then, we pretty much ignore it.

Second, make sure the change that impacts developers is clearly explained somewhere in the bug comments. If necessary, add a new comment that explains what’s changed and why it’s relevant to developers, or at least says “Comments X, Y, and Z are relevant to developers.” This will reduce the likelihood that we’ll have to hunt people down and ask a lot of questions in order to ensure that the stuff gets written up adequately.

Third, if there isn’t really a good bug in Bugzilla on what needs to be written, feel free to file a new bug against the Mozilla Developer Center’s Documentation Requests component, explaining what needs to be written up. Useful information here includes links to the files that have changed (especially IDL), multiple relevant bugs, etc.

In all cases, including information about who would best be able to answer questions about the topic would be extremely helpful.

You can pretty safely assume that if your material isn’t either tagged as “dev-doc-needed” or filed as a bug against MDC, it won’t get written about. The sooner either of these is done in the development cycle for a given release, the more likely you are to get good documentation written, because this helps me schedule writing work to ensure that there’s time allotted for everything.