With the exception of a couple of questions about the non-standard referenceNode and pointerBeforeReferenceNode properties, I’ve completed the documentation for NodeIterator.
My questions revolve around not actually knowing what those two properties do, for certain, although I presume that referenceNode lets you peek at the node currently referenced without moving the iterator.
Next up, I plan to start working on the documentation for @font-face.
One of the biggest challenges of user experience design is predicting what the user wants. The best system possible is one that knows what you want completely and provides it before you ask. The worst system is one that thinks it knows what you want but is always wrong. An example of the former is sitting down to your computer in the morning and seeing the two new sites you always open first ready and loaded. An example of the latter is Clippy, the adaptive menus in Microsoft Office 2003, and any scene from the Jetson’s.
Two ways to predict what the user wants are by 1. knowing him better, and by 2. having more intelligent tools. A browser knows you go to Huffington Post and the New York Times every morning, because it sees your daily browsing habits and knows you’re liberal scum. But if a task is common and difficult, sometimes a more intelligent tool can be the fix.
Here’s a more intelligent tool to get excited about: content-aware image resizing in Photoshop 4 (hat tip: Frederic Wenzel). This feature lets you resize an image while respecting its subject and complexity by scaling the non-complex, boring bits. Adobe has a promo video up, and here is a video from the Israeli researchers who thought of it first. This is a photo editing task which is normally quite difficult and tedious, and with better tools the user experience is massively improved.
Last week we finished up the Beta2 Release for MozMill.
You can install it from AMO.
We’ve been gathering feedback from our Beta1 release and pushed out another incremental beta release before the big push for MozMill 1.0 RC1.
One important thing we did was improve the inspector workflow. It’s much smother clicking on an element and coming back to the Inspector. The inspector also gives you much more information now, including what document you should be passing the Elem you create and what method you should use to create a controller for the window you’re testing.
Lot’s of bug fixes, special thanks to Tony, Tracy and a big hug to Farhad for feature suggestions and filing bugs against beta1.
This release does not include the new framework that hooks up to jsbridge, and therefor isn’t ready for full continuous integration, that’s now in trunk getting worked on for the RC1 release.
On Tuesday, we launched Mozilla Labs Geode. It’s had great response, and we’ve seen websites embracing the standards-based geolocation all across the web.
There’s also been a bit of confusion about how Geode + Firefox 3.0 is related to what’s coming up in Firefox 3.1, as well as why location is a useful thing to have on a laptop/desktop computer.
One of the reasons for Firefox’s popularity is that it is so respectful of the user’s privacy and safety. With something as important as location, no amount of failure to respect the user’s desires is acceptable.
There are a two main moving parts in implementing of geolocation. Let’s break them down.
Javascript Geolocation API: The Javascript API is what allows any website to request and process geolocation data. It’s a W3C standard, so the the API will be constant across all browsers, as well as between Geode and Firefox 3.1.
Location Provider: The location provider provides geolocation data to the Javascript API. In the Firefox 3.1 beta, there are currently only two providers: one to let the user enter their location manually, and another for any GPS device connected to the computer via a serial connection. It’s possible to add more providers, or to remove them. We aren’t sure what providers will come by default with Firefox, and we are looking for feedback.
Geode is meant as a temporary solution to allow websites to experiment with geolocation today. Unlike Firefox 3.1, it doesn’t afford the user a choice of geolocation provider. Skyhook is built in. A side effect is that Linux isn’t supported for the simple reason that Skyhook hasn’t implemented Linux drivers. Although not ideal, it’s okay because Geode is only a temporary add-on.
There are two parts to this answer.
(1) We shouldn’t allow the web to fragment; the web shouldn’t have fundamentally different abilities on a mobile device than on the desktop. That leads us back to WAP versus HTML thinking. Geoocation, address book, and access to the camera may be seem more apropos to mobile devices on first blush, but removing them entirely from the desktop nips entire areas of innovation in the bud forever. That has a chilling effect on the web as a whole, as well as continuity of experience across all devices.
(2) There is an entire gamut innovation that geolocation enables, from obvious to obscure.
There are first-order experiences enabled by geolocation in the browser. These are of the variety, “I am here, so I should see content that is filtered by my location.†Outside.in, Everyblock, and Food Finder are examples.
There are the social aspects of geolocation. These are of the variety, “I am here, and so are/were my friends.†Brightkite, Pownce, and Twitter are examples.
And then there are the second-order experiences of the variety, “I am here versus there, so alter my experience.†This is where most of the unexplored areas in geolocation on the desktop come in.
We’ve already mentioned an RSS reader that knows the difference between home
and work and automatically changes it’s behavior appropriately, and Web site
authentication that only allows you to login from certain physical
locations, like your house. But there’s a lot more. Like virtual capture the flag. Or different playlists for different parts of the house. Or having your computer automatically turn off the lights (if you’ve forgotten to) at home when you plug in at work. Or phoning home if you computer gets stolen — with the location of the thief. Or…
If location was stored in the Places system, Firefox could modify the browser’s behaviors to be optimized for home versus work. It might even not list, in the Awesome Bar, a certain site that you visited from your bedroom after 11pm. Firefox could let you search for sites you’ve been to by remembering where you were when you did the search, or have smart bookmarks for “bookmarked at home†and “bookmarked at workâ€, or show a map of your browsing history. (Thanks to Dietrich Ayala for these ideas).
Today’s xkcd comic boils down the Digital Restrictions Management dilemma to its core:
The latest Wal-Mart example–switching off their DRM servers (in spite of their later decision not to do it after all)–has shown that companies are not willing to stand by their self-imposed duties of providing a DRM framework for many decades to come. Instead, they are taking away the technical possibility to play your files at their sole discretion, leaving you as a customer with no choice other than throw away your media collection–or violate the law.
This is why DRM is so bad: While it is understandable that companies want to protect their income sources, by demanding payment for the media they produced, DRM is making promises the companies do not want to hold, or in some cases (read: bankrupcy) can’t hold. This is why I prefer, at least at the moment, Amazon MP3 over the DRMed part of iTunes any day of the week.
And while Wal-Mart does not exactly have a great reputation as a whole, there’s one thing they’ve thoroughly understood: The concept of capitalism. So it comes to no surprise that they (along with Amazon, for example) exert pressure on the music industry to be able to sell DRM-free music. The market demands DRM-free digital media that can be owned like a record or a CD and slowly, very slowly, content providers are forced to acknowledge that.
I can’t help but wonder, though, is this development going to include digital video as well, any time?
Attendees: djst, zzxc, Cww, nkoth, myles7897
Sumo
Knowledge Base
Support Forum
Live Chat
SFD
History will tell that George W. Bush has been a great, very great President of the United States
Silvio Berlusconi, Italian Prime Mininster, Columbus Day 2008
George, please, in November take Silvio with you.
Many thanks.
I’m re-posting this from Gen because it’s worth watching. Yes, it’s long, but Paul Krugman is funny and some of his words are creepily prescient.
I didn’t think we’d be doing any notable windmill releases until 1.0. Boy was I wrong!
On Wednesday Adam messaged me and said that the windmill startup time was too slow. He was right, we’ve know about this for a while but hadn’t put a lot of serious thought in to how we could reduce it.
The issue here was was that we have about 50 JavaScript files that need to get loaded for windmill to start.
Enter windmill-compressor, a new url namespace we added that concats all the js windmill needs in to one file and minifies it. We do this dynamically when windmill starts up, because adding a “build†step would just be too….. Java.
That reduced the startup time from 5-10 seconds to around 2 seconds. But that wasn’t good enough. We saw that most of that startup time was blocking waiting for the compressor to finish, so I threaded it when we start the windmill service and it does the compression while we wait for the browser to start up.
In all, windmill startup times are about 10x faster than 0.9!
Adam also decided to make our page load wait code a bit more aggressive which made not only startup times faster but all of our tests!
We tied up the loose ends on the JavaScript testing framework and it can now shutdown all of windmill in it’s own teardown, hello continuous integration for native JavaScript tests 
This was the last thing holding us back from promoting this along side the Python test authoring library.
In 0.9 we introduced Firebug Lite integration for windmill on all browsers. But when you’re using Firefox you probably still want to use the full Firebug extension, which is easy enough to integrate since we use mozrunner for Firefox launching.
Windmill now has a “firebug†command line argument that installs the full Firebug
extension when launching Firefox.
Today we’re announcing the formation of a new group that will focus on the research and development of developer tools for the open Web.
We believe that there’s tremendous opportunity for innovation in tools that increase developer productivity, enable compelling user experiences, and promote the use of open standards.
We’re also excited to announce that Dion Almaer and Ben Galbraith, co-founders of Ajaxian, the Ajax Experience, and long-time supporters of the open Web, have joined Moziila full-time to lead this newly formed Developer Tools Lab.
We’re just getting started, so please stay tuned for further details and information on getting involved.
Everything is on the table, from services to software, and we’re looking forward to working with Web developers from around the world to create, experiment and play with new ideas!
Over the weekend, I did some cleanup work on the documentation for media queries and various other topics; these should all be in pretty good shape now.
This morning, I wrote up the documentation for the MozAfterPaint event (courtesy of the blog post by roc that went up while I was asleep, which made the work much, much easier).
Remember: in open source, there’s no such thing as plagiarism. 
Lots to do but the progress is great.
Komodo 5 in under construction but developers can start to appreciate the new features working with alphas and SVN sources…
Another weapon is available to Komodo extension developer, version 5 make easier to be informed when the document attached to a view changes.
A couple of new events (remember notifications are no more supported for view operations) are finally available
Both events put into event.originalTarget the view involved and the view.document object is never null.
Obviously can be null the view.document.file property, for example when user chooses File|New File… from menu.
The code shown below creates a new document and attaches it to the current view, developer doesn’t need to notify using its own code but it is sufficient to listen the standard view_document_attached
var uri = “..â€;
var newDoc = Components
.classes["@activestate.com/koDocumentService;1"]
.getService(Components.interfaces.koIDocumentService)
.createDocumentFromURI(uri);
newDoc.load();
// At this time Komodo 5 fires the view_document_attached event
ko.views.manager.currentView.document = newDoc;
The well known 4.4.x notification/event view_opened has been fixed on Komodo 5 to have the document property correctly set.
Prior Komodo 5 the view sent during notification had (amazingly!) the document set to null 
The view_opened and view_document_attached are strictly related, when a file is opened the view receives both events.
Klint will use view_document_attached to disable syntax checking based on file path regular expressions (eg disable syntax checker for all “.*log†files)
     Â
Due to popular demand, we’ve created a very experimental API for Firefox 3.1 to fire an event every time content is repainted. The event is is called MozAfterPaint and is fired at the document, bubbling up to the window. The event offers two attributes, clientRects and boundingClientRect, which tell you what was repainted, using the same objects and coordinate system as the getClientRects and getBoundingClientRect methods.
This is very useful for Firefox extensions and other “chrome†code that might be using the canvas.drawWindow method to capture the contents of windows. It might also be useful for tools like Firebug. But it’s also potentially useful for regular content, for example if you want to add some lightweight JS instrumentation to a page to measure what gets painted by Firefox, and when.
Caveats:
Hi Everyone,
Just another friendly reminder to join us Tuesday in #bugday on irc.mozilla.org :
*Tuesday, 14 October 2008 :*
* Asia session - 14:00-16:00 (Beijing)
* Euro session - 14:00-16:00 (Berlin)
* Amer. session - 12:00-14:00 (Los Angeles)
So we are about to embrace more MBPs with more Nvidia components, amongst all the rumor mills that are now flying about.
And I got hit by this Nvidia fiasco, and the dear MBP is now in servicing for “3-4″ working days. (It occasionally fails to have any display after wake from sleep, and yes, I considered the Safe Sleep possibility.)
Back to XP on the desktop for the moment. :-/
For those who don't follow the Web-Tech blog --- you should. But anyway, support for SVG filter, clip-path and mask on non-SVG content landed on Gecko trunk a while ago and is in Firefox 3.1 beta 1. Also, I've proposed these extensions to the SVG WG for standardization.
Even more exciting is that Boris Zbarsky did an awesome job of implementing external document references --- I'm not sure if that made beta 1, but it will definitely be in beta 2. This means that all code that uses nsReferencedElement to track which element is referenced by a given URI/fragment-ID now automatically supports referring to external resource documents --- i.e. URIs of the form foobar.xml#abc. And Robert Longson has done a great job of migrating our last remaining SVG URI-ref users to use nsReferencedElement --- that is, markers and textPath --- so as of today, all the places where we support SVG referring to elements by ID support referring to elements in external documents as well as the current document. (It also means they're all "live for ID changes" and safe to use with incremental loading of SVG documents.)
The combination of these features is particularly cool because it means you can now apply SVG filter/clip-path/mask in regular HTML (non-XHTML) documents by placing the effect definitions in an external SVG XML file.
We're pretty much done for new features in Gecko 1.9.1 at this point. Looking forward post Gecko 1.9.1, we will be able to build on the external resource document loader to support SVG fonts (including via CSS @font-face) and SVG images (for CSS background-image etc, and HTML <img>). They should be a top priority for Gecko 1.9.2 or whatever it ends up being called.
At this point most of my "bling branch" has landed, except for two features: SVG paint servers (gradients and patterns) for non-SVG content, via CSS background-image, and the "use any element as a CSS background-image" feature. I'm not sure what to do with them. The former probably should land at some point, but it's not a high priority for me at the moment --- maybe I'll roll it into SVG background-image support, since they're closely related. For the latter, my current thinking is that some uses are adequately served with a CSS background-image referencing an SVG pattern containing a <foreignObject>, and other uses really demand an API that lets you specify a particular DOM node to render (e.g. to mirror a particular element in a particular IFRAME).
For that case, I think the way to go is to to create a new element --- some sort of viewPort element that acts like a replaced element and renders the content of some other element. It would have an attribute href that lets you declaratively specify a URI to the element to render, but it could also have a setSource(node) API so that you can give it a specific DOM node to mirror. You could even have an allowEvents attribute that lets events pass through the looking-glass... Right now MozAfterPaint and canvas.drawWindow are the best way to do effects like that, but they're not optimal. (Although there are uses for MozAfterPaint that the putative viewPort element would not satisfy, such as paint flashing/logging for debugging tools.)
Drawing an image on the screen should be a simple operation. However, in a browser engine, things get complicated because there are a number of subtle requirements involving subpixel layout, scaling, tiling, and device pixels. We've had lots of bugs where visual artifacts appear in sites at certain zoom levels, and we've fixed most of them but the code got really messy and some bugs were still not fixed. So several days ago I sat down and worked out what all our known requirements for image rendering are. Then I worked out an approach that would satisfy those requirements, and implemented it. As is often the case, the implementation revealed that some of my requirements were not strong enough. The resulting patch seems to fix all the bugs and is much much simpler than our current code.
The problem at hand is to render a raster image to a pixel-based device at a specified subpixel-precise rectangle, possibly scaling or tiling the image to fill the rectangle. We control this by specifying two rectangles: a "fill rectangle" which is the area that should be filled with copies of the image, and an "initial rectangle" which specifies where one copy of the image is mapped to (thus establishing the entire grid of tiled images). There may also be a "dirty rectangle" outside of which we don't need to render. There are several requirements, the first three of which are actually more general than just image rendering:
In Gecko, we achieve the first three requirements by rounding the subpixel output rectangle top-left and bottom-right corners to device pixel boundaries, ensuring that the set of pixel centers remains unchanged.
When content is rendered with different dirty rects, the pixel values where those rects overlap should be the same. Otherwise you get nasty visual artifacts when windows are partially repainted. Let the "ideal rendering" be what would be drawn to an "infinite resolution" device. This rendering would simply draw each image pixel as a rectangle on the device. Then image pixels which are not visible in the ideal rendering should not be sampled by the actual rendering. This requirement is important because in the real Web there's a lot of usage of background-position to slice a single image up into "sprites", and sampling outside the intended sprite produces really bad results. Note that a "sprite" could actually be a fixed number of copies of a tiled image...(This may need further explanation. Good image scaling algorithms compute output pixels by looking at a range of input pixels, not just a single image pixel. Thus, if you have an image that's half black and half white, and you use it as a CSS background for an element that should just be showing the half-black part, if you scale the whole thing naively the image scaling algorithm might look at some white pixels and you get some gray on an edge of your element.)
The exact ratio of initial rectangle size in device pixels to image size in CSS pixels, along each axis, should be used as the scale factors when we transform the image for rendering. This is especially important when the ratios are 1; pixel-snapping logic should not make an image need scaling when it didn't already need scaling. It's also important for tiled images; a 5px-wide image that's filling a 50px-wide area should always get exactly 10 copies, no matter what scaling or snapping is happening. Here's a subtle one... Suppose we have an image that's being scaled to some fractional width, say 5.3px and we're extracting some 20px-wide area out of the tiled surface. We can only pixel-align one vertical edge of the image, but which one? It turns out that if the author specified "background-position:right" you want to pixel-align the right edge of a particular image tile, but if they specified "backgrond-position:left" you want to pixel-align the left edge of that image tile. So the image drawing algorithm needs an extra input parameter: an "anchor point" that when mapped back to image pixels is pixel-aligned in the final device output.It turns out that given these requirements, extracting the simplest algorithm that satisfies them is pretty easy. For more details, see this wiki page. Our actual implementation is a little more complicated, mainly in the gfx layer where we don't have direct support for subimage sampling restrictions (a.k.a. "source clipping"), so we have to resort to cairo's EXTEND_PAD and/or temporary surfaces, with fast paths where possible and appropriate.
Note: this algorithm has not actually been checked in yet, so we don't have battle-tested experience with it. However, we have pretty good test coverage in this area and it passed all the trunk tests with no change to the design, as well as new tests I wrote, so I'm pretty confident.
This past week Yahoo! was on campus for their annual HackU event. This is the third year they have been doing it and each year it has gotten progressively larger.
The first year (2006), I think there was a single entry. I made it in time for the presentation and was pretty sad I hadn’t had a chance to make anything.
Last year, I made a determined effort and hacked together my own entry – yWeather – and contributed to flolcatr. These were among the six or so entries from Carnegie Mellon. I didn’t win anything, though I’m still pretty proud of yWeather. There was a 24-hour hack session on the last night, but I’m pretty sure there was nobody there after midnight.
This year there were 28 hacks! I was simply astounded at the number and variation of the entries this year. There were technically impressive hacks, humorous hacks, hacks that could change the web, and even some creepy hacks. We had some big hacker names from Yahoo! show up – Rasmus Lerdof (creator of PHP), Kent Brewster (hacker extraordinaire), and my new pal Paul Tarjan (creator of Search Monkey). I think there were people who actually pulled off the 24-hour hackathon, staying up the whole night. I know Paul was there when I left around 6am.
Last year I took advantage of the time and spent the week working on my hack. This year I didn’t start until after midnight. I contributed a little bit to a hack (“lolmonkeyâ€) with Mattt Thompson which uses Search Monkey and creates an infobar in Yahoo! search results lolifying an image on the linked page. While not the craziest hack, we had fun with it. I think at this point we are both officially done creating tools/hacks that have anything to do with lolcats.
The other hack that I worked on uses the Yahoo! Blueprint framework for creating mobile applications. While not the most technically advanced hack, I think it was one with the most immediate value. It was called “CMU Bussesâ€, and simply tells you the next 5 busses leaving Carnegie Mellon in either direction. You can see a screenshot on the project page. This is something I’ve been wanting to make for a long time, and something I would actually use (no offense to the other hacks). This was a true “hack†– I’m scraping the PAT website with Ruby. My Ruby code is outputting PHP code (the departure times are hardcoded instead of doing a DB lookup). Then the rest of the script is using the PHP Blueprint framework that Yahoo! provides (after spending a while working it out).
I had originally planned to make this an iPhone application, but having never done Objective-C, I figured now wasn’t the time to start. I had also wanted this application to be able to detect the user’s GPS coordinates and find the closes 5 bus stops before showing departure times, but that had some barriers as well. In a future iteration hopefully we’ll see that. The Blueprint framework is supposedly also able to convert a Blueprint application to an iPhone application, but that has not been released to the public yet. When it is released, I think I may publish what I have now as a first iteration.
I got to hang out with some great people throughout the week. I also got treated to a dinner for all of the former Yahoo! interns at Fuel & Fuddle. It was a good time, getting to talk some technology and design with smart people.
As a result of working on the lolmonkey hack, Mattt and I were invited to dinner by Alicia at Bug Labs. They have a really cool product called BUG, which as they say on their website, “is a collection of easy-to-use electronic modules that snap together to build any gadget you can imagineâ€. I got to play with one and it’s really neat. I wish I had some spare cash to get one. They also have some of the coolest package design I’ve seen in a while. So if you’re interested in hacking hardware, take a look at them – they’re cool people with a cool product, hacking on open source hardware and software.
Approximately a month ago, I posted about a discussion I started in the Contributors forum, to gather ideas criteria for an improved Knowledge Base article editor. There is still time to post your thoughts and feedback about what problems you have with the current editor and ideas on how to solve those problems.
For instance, the problems gathered so far are:
Some of the proposed ideas for solving these issues are:
There’s still time to add more ideas and feedback, and we want to make sure everyone has a chance to contribute to the discussion. If you would like to add anything, please post in the discussion thread. Thanks!
The new feature called “content-aware image resizing†in Photoshop is amazing. There is a promotional video up on the Adobe site that’s really fun to watch. For example, they make a Volkswagen bus more “economical†(mind you, while keeping the wheels round):
The technology behind it is based on research from an Isreali research group. That group put a video up on youtube in 2007 already:
It’s a little more technical, but no less impressive, so all of you geeks who wonder how it actually works should watch this as well.
I can tell you one thing: I want this in Firefox’s page resizing code. Sadly, I assume it is strictly patented and Adobe will probably have made sure to have some sort of exclusive deal on it.
Update: A commenter points out, there is an open source plugin for the GIMP that does content-aware resizing–already since 2007. Thank you, Gandalf!
In case you don’t know who James Howard Kunstler is, allow me introduce you. Mr. Kunstler is a very interesting man. I’ve been casually reading his stuff for the better part of a decade. And he’s notoriously cranky. Bruce Sterling included something that he wrote in a post on wired that includes some pretty awesome stuff:
Some big questions for the week: will the Euro survive as a currency? Will the rush into the U.S. dollar continue even as the U.S. financial system dematerializes in a Fibonacci fever of accelerating de-leveraged infinitude? Will the remaining Big Boyz, Goldman Sachs and JP Morgan succumb to the counter-party hemorrhagic fever? Will great rows of lesser banking dominoes now start clacking onto their faces? Will all fifty states follow the leads of California and Massachusetts and line up at the U.S. Treasury’s hand-out window. Will the entity that calls itself the civilized world be left at week’s end with anything resembling money?
I’m certainly don’t believe all that Mr. Kunstler says, but I always enjoy the way he says it.
And now, because you’ve been so patient, here’s Mr. Kunstler talking at TED a few years ago. Some really great commentary on the American landscape. And it’s really funny.
Note: his first book, The Geography of Nowhere is actually a really wonderful read. He wasn’t quite as cranky back then.
I found (and fixed) one of our bugs in the Windows Mobile font code. This makes things much better
![[image]](http://mowser.com/img?url=http%3A%2F%2Fpeople.mozilla.org%2F%7Eblassey%2Ffennec_acid.PNG)
88/100, not bad
![[image]](http://mowser.com/img?url=http%3A%2F%2Fpeople.mozilla.org%2F%7Eblassey%2Fmybrowser_fonts.PNG)
Also note that I’m running this on an actual device, using Remote Zoomin to get the screen shot.
Just to update Doug’s post we’ve got the problem with web content not painting fixed.
Still have problems with fonts though.
Today, I have just pushed a patch that enables Growl support for Thunderbird and SeaMonkey (Growl runs on Mac OS X). Now when you get new mail, you can get Growl alerts like:
A big thank you goes to David Humphrey who supplied the patch.
There are some known bugs with the implementation and we welcome any help in resolving those.
Note for IMAP users: it seems that if you have a folder selected for offline use, then new mail notifications are not occurring as they should do.
I wrote a post about my FBTrace Console extension a few months ago and as it turned out that the console is actually quite useful for exploring how Firebug works internally, it's part of the Firebug's code base now.
This new feature is integrated in Firebug 1.3X (still in alpha phase), where X means: the version with tracing enabled.
The primary purpose of the console is to display a list of tracing messages coming from Firebug as it runs. It's often tough to debug a debugger by another debugger and so, having the possibility to inspect logs is often really invaluable.
Notice that tracing-console is *not* the same as Firebug's Console panel. Console panel is intended to be used by web applications developers, while tracing console is for Firebug (or Firebug extension) developers.
So, move on if you want to see how it works...
For those of you following the Firefox/Gecko platform development, or for those interested in helping out, this is a call for participation. If you’re not afraid to get your hands dirty a bit and would like to help the Firefox accessibility team, now would be a good time to get involved!
The problem: The code that calculates the names for any created accessibles has been growing over time and became largely unmaintainable. New features suich as adding the aria-label property support requires code duplication for HTML and XUL, and in general the code has many stylish un-niceties.
So, our team has started a code cleanup and code refactoring series to get the code into better shape and maintainability.
As with any refactor, the result should be identical in output with what we started out from. However, as those of you familiar with software development know, the risk of regressions is there and should not be discounted.
While we do have test cases for many of these instances already, there may still be cases we’ve missed. So any help we get from the community will help make sure that the refactor goes smoothly, but also help fill in any possible gaps in our testcases.
So, how can you help? By downloading and installing the latest nightly builds of Firefox 3.1 for Windows or Linux, and testing the heck out of them. Use your favorite screen reader, use your familiar web sites, use it for day-to-day surfing. Obviously the most likely pages you’ll find differences on, if any, will be those pages you visit frequently, sites you know what the output should be.
If you find something that is different from what you know, you can download the last Windows or last Linux build before the refactor, unzip it into a separate folder, and compare your findings using that build.
If you find differences you did not expect to find, you have two main choices that will get the developer team’s attention:
In any case, your bug report should contain the URL of the page you are experiencing the difference with, the expected output of the element, and the output you’re now getting. Also, is that element a graphic, link, heading, form field etc.? Also, you should mention what screen reader you’re using. If posting to the newsgroups, it will also help to mention the operating system.
How to update the nightly builds to pick up latest code changes: The builtin Check for Updates feature, if invoked from a nightly build, will always grab an update to the latest nightly build and install it for you. So, you only need to download and go through the installation process once. You can then daily check for updates and get the latest code that way.
The first build to see changes will be the October 11 build, build ID 1.9b2pre/20081011.
Working with different profiles: If you don’t want to put your regular profile into the hands of the Firefox nightly builds, you can start Firefox.exe or the ./firefox executable with the -p option to bring up Profile Manager. You can then create a new profile and start Firefox with that profile. That way, your Firefox 3.0.x profile won’t be touched by the 3.1 nightlies if you choose not to. I’ve found, however, that the nightlies are very stable already, and I often flip back and forth between 3.0.x and 3.1 builds on the same profile without problems. The one thing that most certainly would happen is that some extensions may not work in 3.1 yet.
I’d like to thank all of you in advance who decide to participate in this effort and help everyone who relies on Firefox accessibility by testing out the code refactor. You can make a real difference because we obviously can’t test all of the web pages out there, and yours may just be the one we might miss out on.
Powered by ScribeFire.
I mostly spent today twiddling documentation I wrote over the course of the week. Little fixes as suggestions come in, a few organizational corrections, that kind of thing. It was a great week of work, and I’m really pleased.
There are some moderately significant corrections remaining to be made in the media queries documentation; I plan to work on that tomorrow.
I’ve been getting fantastic feedback, which I really appreciate. I’m sure there’ll be plenty more!
An unfortunate typo in a configuration file left this blog completely without images for a little while. Apologies to the readers who may have been confused by that.
Now, fredericiana is back in all it’s glory 
On a side note, I am actually glad how nice my blog still looks with images “disabledâ€. Still, I am glad everything is back to normal now.
Last week in the frenzy leadup to FF3.1b1 code freeze, we got into a state where there were too many changes and too many builds being queued for the available pool of slaves to keep up. Literally, there were new builds being requested faster then we could generate builds. Worst hit was win32, because win32 builds take much longer then the other platforms.
Short answer: Since early summer, we’ve used double the number of slaves we had for FF3.0 - which was more then enough until last week. We’ve since added even more slaves to the pool, which cleared out the backlog and also should prevent this from happening again. At peak demand, jobs were never lost, they just got consolidated together. Having multiple changes consolidated into the same build means the overrun machines can keep up, but makes it harder to figure out which specific change caused a regression.
Long answer:
First, make some coffee, then keep reading…
If you recall from this earlier post, we’ve moved from having one dedicated-machine-per-build-purpose, to now using a pool of shared identical machines. Pending jobs/builds are queued up, and then allocated to the next available idle slave, without caring if its a opt-build, debug-build, etc. Any slave can do the work. More importantly, failure of any one slave does not close the tree.
Related topic is: its tough to predict how many slaves will be enough for future demand. We started in early summer2008 by having twice as many builders as we had builders on Firefox3.0. That guesstimate was based on the following factors:
This worked fine until last week when a lot of changes landed in the rush to FF3.1beta1, and then regressions forced a lot of back-out-and-try-again builds. Here’s a graph that might help:
![[image]](http://mowser.com/img?url=http%3A%2F%2Fwww.oduinn.com%2Fimages%2F2008%2Fblogpost_pool_capacity.png)
Once we realised the current pool of machines was not able to keep up with demand:
Looking at the graph again, we dont know if we will see “future#1″ or “future#2″. We’re still unable to predict how many slaves is enough for future demand. We’re adding new project branches, hiring people, adding tests. We’re obsoleting other project branches. Once we fix some infrastructure bugs, we can stop “waste†builds completely. Either way, the infrastructure is designed to handle this flexibility, and we have plenty of room for quick expansion if need arises…
We dont yet have an easy way to track how heavily loaded the pool-of-slaves is, so I have to ask for some help.
Until we get a dashboard/console working, for now, can I ask people to watch for the following: Whenever you land a change, an idle slave should detect and start building within 2 minutes (its intentionally not immediate - there’s a tree stable timer of a couple of mins). If we have enough slaves, there should be one build produced per changeset. Its possible, but rare, that people land within 2 mins of each other, and therefore correctly get included in the same build, but that should be very rare. More usually, each checkin would be in a different build. If you start seeing lots of changesets in the one build, and especially if you see this for a few builds in a row, it may mean that the pool-of-slaves cannot keep up, and queued jobs are being consolidated together. In that situation, please let us know by filing a bug with mozilla.org:ReleaseEngineering and include the buildID of the build, details on your changeset and the other changesets that were also there, which o.s., etc and we’ll investigate. There are many other factors which could be at play, but it *might* be an indicator that there are not enough slaves, and if so, we’ll quickly add some more slaves.
Hope all that makes sense, but please ping me if there are any questions, ok?
Thanks for reading this far!
John.
Brad Lassey posted some emulator pictures just a bit ago. Here is one picture of the Fennec on a windows mobile device:
yeah, so there are some glaring problems (like, uh, not painting the web content…). Getting this far is a huge milestone. Thanks to John Wolfe, Brad Lassey, Brian Crowder for pushing on this port.
Now is the time to get involved! Check out the build instructions, and join us on irc (irc.mozilla.org #wince and #mobile).
     Â
With all the bad news that threatens to overwhelm us sometimes we need a little good news for a change. Here’s a fun, if somewhat corny video of the SpaceX Falcon 1 Flight 4 launch set to music. Relax, stop worrying for a moment and just enjoy the thought of private space travel.
Windows…. we got windows!
Its reasonably fast on the device too (just harder to get a screen shot). Some obvious font issues though. Stuart, tag… you’re it.
As the scope and depth of the Socorro/Breakpad project has evolved in the last nine months, the most nonvolatile requirement of the project has been a file system as the initial server side storage for submitted crash dumps. The file system gets used as an ad hoc hierarchical database, but it isn’t optimized for the type of lookups that we need to do. Unfortunately, the original implementation was without indexing by name leaving us using a search (sort of like using find over NFS with 9 million entries). We patched and then patched the patches as the magnitude of our scaling problem erupted in front of us. Now that the emergencies are over and server side throttling is in place, we can revisit and re-engineer a proper interface for the file system.
Indexing by a single key is simple in a file system. The path is the key to a file. Indexing by a second key in a file system requires links. We chose to use symbolic links as our pointers to indicate relationships between files. There’s an interesting thing about symbolic links: if the path they point to isn’t too long, the path is stored right with the inode. Reading the target path from a symbolic link is fast. We created two radix sort hierarchies, one for the name and one for date. We store our uuid named data files on the name branch. Then we have symbolic links span the gap between the branches to indicate the time interval in which a file was submitted.
Our applications use these two hierarchies in a certain order every time. On first reading the file system, we’re looking only for dumps that we haven’t seen before. We walk the hierarchy on the date side and we know that every symbolic link we encounter represents a new crash dump. We pass the uuid on to the next application for processing and then we remove the symbolic links. That guarantees that any link we find on the date side is always new. From then on, we only will need to lookup that uuid by name. The remaining hierarchy of the name branch is optimized for that.
We also use this hierarchy for long term storage of crash dumps using a different file system root. Using the name branch, we can look up files by uuid very quickly even if the number of stored files is huge. When it’s time to retire old data that is no longer needed, we can walk the date branch to find and delete only items older than a threshold.
We expect this new system to speed up priority processing significantly. The uniform API embodied by our new class JsonDumpStorage will increase reliability and consistency across the applications that use the file system.
For more information, see: SocorroFileSystem
For progress information on deployment: Bug 458798
SVG external document references have landed on trunk in time for the second beta of Gecko 1.9.1 (and Firefox 3.1). What this means is that the SVG element being used as a fill, clip path, mask, filter, <svg:use> target, or marker no longer needs to be in the same document as the element being filled, masked, filtered, etc.
In particular, what this means is that the preceding post about SVG Effects in HTML Content now applies to HTML documents, not just XHTML. I’ve put up a small demo showing how the whole thing works. Give switching from the “default†stylesheet to the “alt†stylesheet a shot.
The one caveat is that for the time being all the external resources must come from the same origin as the main page. This mitigates several possible security issues. Longer term, we plan to mitigate some of these in other ways, and then allow cross-site linking subject to the Access-Control specification.
What is a computer? You’d think that would be a fairly simple question. After all, I’m using one to type this up, I ought to know what it is, right? I mean obviously, it’s a…computer! I mean, it’s got a keyboard, and a monitor, and there’s that box down there…
But what is it that makes all that stuff a computer? Why do we look at it and go, “Oh yeah, that’s a computer,†as opposed to, say, “Oh, that’s just a TV,†or “That’s where I keep the leprechauns at night.�
Some people try to define the word “computer†just by saying “it’s got such and such parts and they all work this way,†but that’s like saying “airplanes have two wings and jet engines.†It’s true, but I could build an airplane that didn’t have two wings or jet engines. The way something works is not a definition for that thing.
Others try to define it mathematically, but that can also be somewhat limiting, because then only the devices that fit into your mathematical scheme are computers, and there are multiple mathematical models that would all be considered “computers.â€
So I turned to the dictionary. That was fun for me–I’m a dictionary fanatic. I’ve got lots of great dictionaries, and there are even more online. The Compact Oxford English Dictionary had the best definition, as it turned out.. I was very happy with it at first, but when I started to think about it, it didn’t quite work. For example, it calls computers “an electronic device,†and we know that computers can be built without electronics.
So I worked to come up with a definition of my own. Strangely enough, the key question that it boiled down to was “Why is a player piano not a computer?†It “processes information†by playing notes from its roll. If you gave it an etching machine, it could “store information†back on to the roll. But despite all that, it’s clearly not a computer. What is a computer doing that is fundamentally different from a player piano, that a player piano could never do?
After about two years, I finally came up with an answer that was both simple and all-encompassing. A computer is:
Any piece of matter which can carry out symbolic instructions and compare data in assistance of a human goal.
And that, my friends, is really it. My only thought left is whether I should say “a series of symbolic instructions†to more clearly differentiate it from a calculator. What do you think?
-Max
I’ve noticed that in order to use the APIs of some web services, they are requiring applications (web based or otherwise) to obtain per-user API keys. This is essentially a generated password (separate from the normal login password) specifically to allow an individual application access to a specific user’s data via an API. It requires the user to manually request an API key for each individual application they wish to grant access to, and then enter it into that application. Sometimes the user is instead forced to manually verify every single action.
In other words, it punishes the user because the web service doesn’t trust the 3rd party application. This is wrong. Its not the user’s fault.
This has come up many times for Ubiquity command authors trying to provide easy and novel access to web services. It means that if commands want to use a web service’s API, they need a setup procedure before they can be used. Which is stupid, because a command already has access to the login cookie, and the login information in the password manager.
I’m not saying that I’m providing a solution for all of this. There are already plenty of other existing methods to choose from - some of which may fit, some of which may be just as bad. What I am saying is that while granularity in access control can be seen as a good thing, it should not come at the user’s expense.
My Spying tool called BrowserSpy moved to it's own website. BrowserSpy.dk is the place where you can see just how much information your browser reveals about you and your system.
Geolocation
For those using nightly builds or the new Geode addon can try my Geolocation test where your location will be shown.
What sites have I visited?
Using a known CSS "feature" BrowserSpy can tell Mozilla users if they have visited a specific website. You can try it yourself. Also see the relevant bug report.
I’ve posted the article “Using geolocation“, which provides introductory information on using the new geolocation API being introduced in Firefox 3.1. I’ll be adding a working example tomorrow (later today, actually, now that I look at my clock and see it’s already Friday). I’ve also not yet documented the interfaces behind geolocation, but I’ll be doing those tomorrow.
As always, if you happen to notice any errors, please feel free to correct them or let me know what needs fixing so I can do it.
Enjoy!
The new Thundertab has (partially) landed in the nightly builds of Thunderbird. You’ll need to get Lightning installed to see all this and it’s not too pretty yet, but we’re making lots of progress.
But there’s no time to lose! We’re already talking about how to handle tab session restore to keep all your opened mail tabs around for future sessions.
I’ve put up a partial mockup already, but it’s still early. As always please leave comments below!