“An Inconvenient Truth”

I rarely blog about non-technical issues here, and even more rarely about non-mozilla.org stuff. I have to say something, though, about the film Al Gore has recently starred in, “An Inconvenient Truth”.

Go. Watch. This. Film.

I liked the film – it’s raising a challenge for all of us. Personally, there’s not much more I feel I can do directly to reduce my impact (I ride a bike, walk, and take the bus just about everywhere except when I’m visiting my parents – I don’t own a car and don’t want one, thank you very much). About the only idea I have would be to start putting holes in paper bags again, so I can stick them on my bike’s handles the same way I do for plastic bags. But that becomes a problem for businesses, convincing them that it’s a Good Idea to carry special paper bags.

Now, if only tickets to the film were tax-deductible. (Hey, it’s Al Gore, right?) 🙂

Another person who (for the moment) hates Comcast

I’m asleep with music playing in the background from Music Choice’s “Soundscapes” channel (New Age music, very relaxing). I hear a song that’s so good and so unusual I find it impossible to ignore. (Kevin Wood, “Harmonic Oasis”, on his “Scenic Listening” album.) Songs like this are why I bought Blue Man Group’s two CD’s when I first had the chance. (For them, it was “Synaesthetic”, which I first heard on a Pure Moods album.)

So I decide to pay Music Choice’s website a visit.

Imagine the fun I had in reading this famous paragraph from Firefox 1.5.0.4 in Linux:

Our service is not currently supported by this browser. For best viewing, use Internet Explorer 6.0 or higher

Okay, so somewhere between ten and fifteen percent of their market doesn’t matter to them. They want me to use a browser that has been declared too dangerous to use, two years ago. We’ve had Firefox for a while now. (I know I’m preaching to the choir here, but wait: it gets better.)

So I have to go back to Windows, and fire up IE. Please have mercy on my poor vulnerable computer, I beg. No such luck. When I get to their webpage, I get an interface that isn’t very user-friendly. But at least there’s a tab for “Get Music”. All right. I click on it.

There are eight entries. Nothing even close to what I’m interested in. No indication of a scroll bar, search functionality, or anything that suggests I might like to pick the CD I want to buy.

I won’t even try to go into detail about the video interviews that are playing that I didn’t ask to see.

This one rates as one of many “Web Pages That Suck” in my opinion. It was so bad that I just had to look up the URL for Vincent Flanders (and write this blog rant, I suppose).

In short, I took my business to Amazon.com, and bought two CD’s from Amazon that I would have just as easily bought from Music Choice… if I could.

</rant>

(Off topic: Remember Tiananmen Square, 1989. It happened today.)

Sending messages from content to chrome (part 3)

UPDATE: This code has not been seriously audited for security holes, and may introduce vulnerabilities. Also, when I wrote it I did not take into account work on Gecko 1.9. Please be aware this code has not gone through rigourous testing.

Several months ago, I came around with a question: how should I send information from a content page to chrome. I wasn’t able to do it by DOM events as bz suggested, so when I did a little thinking, I came up with a solution for ManyOne Networks, Inc., my employer, that I wasn’t able to talk about at the time.

That time has passed. Regretfully, ManyOne has decided not to release the product I was working on, but they’ve no qualms about releasing the source code behind it. Including my special message-passing code.

dust-source.tar.bz2 > components/mnIChromeMessenger.idl and components/mnChromeMessenger.js .

How a webpage uses it:

  1. You create a JS-based object containing all the data you want passed upstairs.
  2. You include a window property, which is the top window you can reach.
  3. You wrap this object in another JS object (which I refer to as wrapper), as its wrappedJSObject:
    /**
    * Wrap a JavaScript object for passing to components code.
    */
    function ObjectWrapper(object) {
    this.wrappedJSObject = object;
    }
  4. Call chromeMessenger.send(wrapper).

This does some minor sanity-checking on the wrapped object (basically, making sure all but a couple properties are numbers, strings, boolean or undefined), and then dispatches a message to Mozilla’s observer service, with a topic of “content-message”.

Now, it’s entirely up to the chrome and XPCOM code to write observers to listen for this particular topic of message. One idea we had was to use this for opening new tabs by script. You’ll find in the tarball’s chrome/portlets/content/navigatorOverlay.js at line 448 a procedure by which we did this. There are some weaknesses in the scheme (notably, this code can’t be used to directly return a window object of the new browser to the caller, and there’s no concept of tabbrowser’s maximum tab count – thus inviting tabbrowser spam), but overall, it would do what we needed it to do.

Personally, I’d like to see mozilla.org review and adopt this code somewhere – say, in extensions/chrome-messenger, or perhaps in the toolkit if the Aviary or Firefox teams want it. I wrote this code for commercial use, and we tested it pretty thoroughly on our company’s product. It works beautifully.

I’m thinking seriously about submitting a bug to get this code checked in, but I’d like your feedback on where in the source it should live, and who wants this capability. If there’s not enough interest, then I won’t file a bug and we’ll just leave it on the sidelines, maybe as a XPI on addons.m.o.

P.S. This is my 300th blog entry. Nice coincidence that it should be a useful one.

Gee, thanks, Uncle Sam

It’s fairly obvious someone’s head is going to roll for the Dept. of Veterans Affairs foulup. This laptop theft and its implications are horrifying – especially to me, since I’m one of those 26.5 million veterans.

I don’t know how many others in our business can say that, and I don’t care too much. But I’ll tell you this: having just in the last two years started to get my life in order and moving in the right direction, I really don’t need the personal and financial trouble this implies. Never mind it hasn’t happened yet. It just became a lot likelier.

26.5 million. Think about that. That means somewhere between five and ten percent of the U.S. population. Chances are if you’re not one of the people affected, you almost certainly are friends with one.

Metadata for XML editors and copy/paste histories, part 1

How many times have you copied something from point A to point B within a document, only to realize you messed up something in point A, and have to fix both A and B?

Personally, I’ve done that lots of times. It’s annoying. If I did that, I’d much rather fix A and let my editor detect the fix, and propagate it to B. It’s the sort of optional feature that would make an editor into a killer app, I think.

Having not yet done any formal research into how others have approached this, I decided to start writing up a spec on how I would do it for a XML editor such as Verbosio. I know I am extremely stubborn and want to try to figure this out – so I’m posting now (before I waste too much time) to see if anyone else has looked into this, and hopefully, written up specs for this before.

In short, I’m starting to design two specs. One for storing metadata about a document that XML editors can commonly use, and one for recording copy/paste histories in that metadata, in order to propagate fixes from early content to later similar content.

Please, someone stop me with some great ideas others have already written about! Otherwise, I will post a blog article later describing the start to a new approach.

UPDATE: Wow, this is hard. I had an idea I was starting to formulate, but then I started trying to simulate it…

XUL Widgets: Textboxes, validation and accessibility

<xul:textbox/> visual examples

This is my initial attempt to give XUL controls a standard set of icons and styling to support new features in XUL Widgets. XUL Widgets will soon support several flavors of <xul:textbox/>:

  • disabled
  • delayed (for when the application wants a time-delay)
  • invalid (for when a control’s value is not valid)
  • warning (for when a control is valid, but the application wants to caution the user)
  • internal-error (a bug internal to the application or widget)
  • OK status (everything checks out)

This is a first draft, and subject to change based on feedback. I asked a11y on news.m.o for some, and got all my replies from /dev/null…

You might be wondering: why would I try to create icons to go with textboxes? The answer is simple: color-blindness is a real and not-so-obvious problem.

I’m also wondering how I can display these icons for people who need the accessibility support, and not display them for those who don’t.

I’ll maintain current drafts of these icons with the XUL Widgets installables fairly soon. (I still have some <xbl:implementation/> code to write.)

A few observations:

  • The tooltips really don’t work in Gecko 1.8. They seem to work nicely in Gecko trunk. (This is a problem until at least the Aviary 2.0 / SeaMonkey 1.1 releases. Help wanted.)
  • In the default Firefox (1.5) theme and in SeaMonkey’s (1.0, trunk) Classic theme, I couldn’t visually tell the difference between a normal textbox and a disabled one without the icon present. (XUL Widgets does a little extra to identically style the textbox itself in a disabled state, with other attributes in play.) The colors essentially matched. This is probably a legitimate a11y bug in the themes.

Comments welcome!

Text styling by Mozilla editor? (part 2)

So I got thorougly roasted on my original idea. Which is actually good, compared to the deafening silence I’ve seen when I post other ideas. 🙂 Believe me, I prefer discussion on my ideas. In this case, it’s helped me abort a bad approach – which is why I post my ideas.

In short, regexps are impractical in the context I had in mind. I refused to give up on this until Daniel Brooks (aka db48x) showed me “the regular expression that parses email addresses”.

So scratch regexp’s.

What I (very roughly) need for XML documents, as I understood db48x’s explanation, is:

  1. Support when parsing the source of the XML document for start and end points in the source text corresponding to the XML tags & attributes of the document.
  2. An algorithm for converting those boundary points into their equivalent contentDocument-in-the-text-editor boundaries (which would be much easier if I store the boundaries as line number + column number)
  3. A way to specify the classes for each set of boundary points
  4. A way to specify the CSS stylesheet for each class.

I was very concerned about performance, but apparently that’s a non-issue.

The first and third items on the list involves probably some XML parser hacking. Of course, I’ve never hacked our expat before. 🙂 The second item is straight mathematics. The fourth I could probably just apply to the editor’s contentDocument, or perhaps hack nsPlaintextEditor to support nsIEditorStylesheets.

For other types of source code (such as C++, JS, etc.), I’d need the same types of constraints as for XML, but not the same constraints. Some way to create a common set of XPIDL interfaces would really be cool, but I’m not at that stage yet. I’m still in the brainstorming-and-learning phase. (Maybe working backwards, from end-of-document to start, may mean not recalculating for offsets and new DOM nodes as iteration continues.)

Here’s the transcript of our conversation: #developers @ irc.mozilla.org on syntax highlighting

As always, your feedback in helping me clarify and organize these thoughts is welcome – as long as you’re informative. (I can take rudeness, but not without references to back it up.)

Text styling by Mozilla editor?

Let’s face it: when you’re editing plaintext in Mozilla, you don’t get any nice text highlighting. It’s just not supported. Having edited raw text (XML documents, JavaScripts, CSS files, you get the idea) many times, I’ve often wanted some support for syntax highlighting, in a simple but very flexible way.

There are really two parts to the problem: (1) Figuring out the method by which text is highlighted (or otherwise “styled”), and (2) Figuring out how to determine the groups of text which are highlighted.

Call me crazy, but the second part I feel can only be answered by regular expressions, like ECMAScript’s.

One idea I had involves reusing the CSS stylesheet mechanism, and a new Mozilla-specific CSS selector (which no one’s proposed yet):

-moz-regexp("/foo/") {
color: #ff0000;
}

The above stylesheet would be applied to a <xul:editor type=’text/plain’/>’s content document, and through some internal magic, would apply the CSS rules to the appropriate text.

Another, somewhat more convoluted, would involve implementing a new XPath function regexp-match("/foo/"), and XSLT stylesheets to transform the source text into a HTML document, similar to what XML pretty printing in Mozilla does. Then use a <xul:editor type=’text/html’/> to display the document for editing. When practical, the editor would grab the post-processed + edited text and re-run it (or at least the changed portion) through the XSLT stylesheet to re-highlight the changes.

A time delay to allow the user to finish typing before repainting the screen would be entirely acceptable. When you factor in DOM mutation events, it’s practically a necessity.

I’m wondering how in the world to do this. If someone could write up a proposal on doing this, it’d make for a really great feature for Gecko 1.9. Any Summer of Code ’06 takers? Anyone else willing to do this?

Does anyone understand what I’m talking about here on the technical side? 🙂

UPDATE (at 3 am) : Okay, I just had a nice 45 minute discussion with Daniel Brooks (aka db48x). Combine that with comments 2-4 on this blog entry, and I’ve got some rethinking to do. New blog entry coming with Daniel’s conversation post-cogitation. In the meantime, your comments are still welcome. (For those of you wanting to preview the conversation, find some #developers moznet logs, roughly from 2:00 am to 3:00 am Pacific time, 06 May 2005.) For now, I’m going to sleep.

XUL Widgets, version 0.2.1

I’ve just released an updated version of XUL Widgets. New features:

  • The SVG+XUL menuitem binding I created earlier this week, a good start
  • Support for mozilla.org toolkit’s update manifests
  • An initial attempt at documentation (yes, the XUL Widgets Manual is starting)
  • A little bit more styling for XUL textboxes (‘delayed’, ‘warning’)

Accessibility is a big concern I have, and I’m going to spend some time tonight making icons for a future version 0.2.*.

XUL Widgets Installation instructions

Note version 0.2.* is NOT backwards-compatible with version 0.1.*. If you’ve installed version 0.1.* of XUL Widgets, please uninstall it before installing XUL Widgets 0.2.*.

A skeptical eyebrow raised

Slashdot points us to this Seattle Times article. Two quotes here that caught my eye:

“AdCenter will give advertisers sophisticated information about consumers, including their location, age, gender and sometimes, their level of wealth.”

“AdCenter will not give any information that can allow advertisers to personally identify a person, he added.”

Uh huh. Suuuuuuuure. If you “locate” me at 1255 Foo Street, Apt. 355, in Santa Clara, and that I’m a 28 year-old male, it’s pretty easy to identify me. Even if it isn’t quite that specific, just mentioning my income will subject me to a barrage of car ads, home mortgage ads, etc. I’m already sick & tired of the Capital One “No Hassle” mail in my postal box (if it’s “no hassle”, why do they keep hassling me to sign up?)

Pardon me for not believing a convicted monopolist.

</rant>

Alex Vincent's ramblings about Mozilla technology, authoring, and whatever he feels like.