I've blogged before about having limited Internet access. The good news is that at home, I now have (at least temporarily) dialup access through a generous benefactor's computer and (with his permission) AOL account.
Add to that some FastLynx software from Sewell Development, and I figured I could just update my tree by running the normal checkout commands.
But when the CVS command takes six hours or more to run a checkout on SeamonkeyAll, I start thinking it's hanging. So, I tinkered around a little bit (that build configuration script is nothing short of amazing) and added a -t option for the cvs command via .mozconfig.
Now I'm reassured that it won't hang. I'm equally reassured that I can't stay up all night to watch for AOL to disconnect me...
I guess I'm back to downloading nightlies and hacking strictly chrome apps... this isn't too bad, considering all I hacked on the lizard was chrome apps...
By the way, leaf, when are we going to see those Windows zip builds in ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest, like you've been promising me for the last 18 months or so on the few occasions we bump into each other? :) Windows installers suck.
http://seattlepi.nwsource.com/local/188368_mtrainier28.html
The reason, he said, is that ozone -- a combination of factory emissions and car exhaust "cooked together" with sunlight -- consists largely of nitrogen oxide, which turns around once the sun goes down and destroys ozone.
Parse that sentence and tell me if I'm reading it right: ozone is self-destructive.
I thought ozone was molecules made up of 3 oxygen atoms...
I've got bad news for you.
Every comment a visitor (including you) tries to post to my weblog, now I have to personally approve before it lands on the site. So, Mr. bob@y####.com, GIVE IT UP. You're never going to see another one of your links on my blog again.
Oh, and if you think you might still get ME to read them? Nope. I use a web-based e-mail service, so I can delete garbage unseen, and more importantly, undownloaded.
For those of you worried about censorship: don't be. If you have something not nice to say about me, but it's fair and intelligent, I'll post it anyway. I'm not doing this to silence anyone other than those who abuse the privilege of this weblog's open commenting system.
(1) I received my new Mozilla shirt in the mail a couple days ago. Fits nicely; I like the style... only one little beef with it.
Couldn't they have put a pocket on it? :)
(2) I'm getting a lot more evil comments on this blog lately. Methinks MovableType will hopefully block out autospamming tools in its next release.
(3) I'm thinking about changing the name of this weblog to "Burning Chrome," referring to William Gibson's work. I don't do too much work on DOM Inspector or documentation... but I do like to develop cutting-edge stuff in Mozilla's user interface. Or, to put it more artfully, to burn chrome.
I've written an 1,100-page book on JavaScript. I've written a MathML editor for Mozilla (pre-release, but still fairly good). I've created new widgets and new ideas for programming in Mozilla. I've dabbled in amateur science fiction that's been rather well-received. And I still haven't gone to college yet.
I'm 26 years old, and I'm working in a job that, while enjoyable, has nothing to do with the sort of stuff I want to be doing. For years, my parents have been telling me to go to college, and I've been saying for years I want to go. But if I keep putting it off... how many companies would be willing to hire me for doing what I love doing: developing web technologies and/or writing about them?
So, I need your help.
I'm calling for any sort of connections (networking in the original sense of the word) that can help me get into college and get a degree. Whatever you think might help me, please let me know through my e-mail and/or this blog (which ends up in my e-mail anyway). Whether it's scholarships, good advice, letters of recommendation, whatever: I need it, and I need it fast.
I've just sent off an exploratory e-mail to the admissions dept. of my local community college. It's a first step, but I pray it's not the last.
After a little floppy hell (I need a new computer badly), I managed to put this out for your consumption. The documentation and launch of the abacus.mozdev.org site should be underway (assuming pete@mozdev can grab the .tar.gz I put up for him too).
It doesn't yet work in N|Vu (I don't know why), and there is a Windows crash bug which this package reveals, but that's the best I could do.
A few weeks ago, I griped about a crasher bug involving DOM appending a node, a bunch of XBL bindings being constructed (descendant nodes of the appending node), and JS not being directly responsible. Fortunately, it was a side case that I could do without for Abacus 0.1.
I didn't want to, but I didn't have a whole lot of choice.
So, in releasing Abacus 0.1, I managed to foul up the directory structure for the .tar.gz and zip releases (which is why it didn't work). It was an ancient bug I'd forgotten about and manually hacked to make work. I put together an XPI for Abacus, and decided I'd better rerelease it as Abacus 0.1.1 -- acknowledging that I goofed on the 0.1 version.
That XPI is finished, and I'm working on the abacus.mozdev.org website for a simultaneous release and documentation of the project.
Except that nagging little crash is back... and this time, it affects me every time I click the "Apply Template" button. Such is a critical piece of the Abacus user-interface, and failure is not (much of) an option here.
Now, here's the weird part: On my Mandrake Linux 9.1 o.s., it never crashes at the same part in my code. So my attempts to get a stack trace detailing the problem are somewhat useless.
Needless to say, I am even less happy than before.
Abacus 0.1.1 will be released concurrently with the launch of abacus.mozdev.org in a few days.
I've been thinking for some time that we should really build some sort of <xul:calendar/> widget in XBL. We'd probably use attributes of the element to change the appearance of the widget (say, one arrangement might be a grid filled with calendar dates, another might be a month-day-year trio of menulists, another would be a day-month-year trio, etc.). A common binding would support the implementation and event handlers; the content bindings would each correspond to a particular view of the element, as determined by attributes.
Does anyone want to start writing one?
A few days ago I wrote about a possible security hole I'd discovered in my own work, and the process I went about in closing it safely.
However, it now occurs to me that, although my particular use-case was protected, the eval() function itself is still a very dangerous function to call from JavaScript chrome.
This is particularly true if the application has loaded the JSLib input/output module, and thus has enabled the application to directly access the filesystem of the client. Chrome files operate in a scope outside the security sandbox model web developers tote (with good reason) as gospel. However, even without JSLib, it would not take a hostile input source long to duplicate the include() function from jslib.js...
Bug 88314 @ b.m.o is an ancient bug for reviewing dangerous eval() calls from chrome. I'm beginning to think that quite frankly, this is not enough! I'm beginning to think that Mozilla would be very wise to completely disable the eval() function when running from chrome, and throw an exception instead.
Here, it becomes a matter of opinion: who's responsible for security in the context of a Mozilla extension? Taking my own project as an example, I very nearly allowed a potential security hole into the 0.1 release.
The hole isn't immediately obvious; the exploit would require loading a template with evil code to execute as an mEdit:execute attribute. Unfortunately, in an effort to be friendly, Abacus would allow an application to specify at runtime where to get its data files from. So a web-served page calling on Abacus could insert its own malicious XML data files, and you get the picture from there.
I closed that one, and hopefully I have no others, but it still begs the question: if I hadn't stopped it, could it have been stopped? The eval() function is part of the ECMA-262 standard, which defines ECMAScript, 3rd Edition. So blocking that one from running inside chrome:// scope would be a violation of ECMAScript.
Who would be to blame if someone exploited eval() for evil purposes from a chrome application's scope? Certainly the chrome application could be blamed for letting it happen... but Mozilla could also be to blame for making it possible.
I'm undecided on whether I should file a bug at Bugzilla asking for Mozilla to specifically disable eval() in chrome. I'd like your opinions on the subject (particularly those of Mozilla developers and the security group).
I would offer a third alternative, though: requiring a second argument to eval() within chrome apps. Say, eval(expr, testFunc), where testFunc(expr) would return true only if it was safe for eval() to execute the expression. Thus, the implementation of eval() could force an application developer to consider security when writing the eval() call. If the developer simply wrote:
eval(x, function() { return true; });
then there's no way Mozilla could be blamed when x says:
"var y = new File('/usr/bin/mozilla');y.open('w');y.write('you are an idiot');y.close();".
Of course, we could just as easily advise developers to say:
if (testFunc(expr)) {
eval(expr);
}
Comments are open!