Shallow Thoughts : : web

Adventures with Virtual hosts and CGI on Apache 2.2

We had a server that was still running Debian Etch -- for which Debian just dropped support. We would have upgraded that machine to Lenny long ago except for one impediment: upgrading the live web server from apache 1 to apache 2.2.

Installing etch's apache 2.2.3 package and getting the website running under it was no problem. Debian has vastly improved their apache2 setup from years past -- for instance, installing PHP also enables it now, so you don't need to track down all the places it needs to be turned on.

But when we upgraded to Lenny and its apache 2.2.9, things broke. Getting it working again was tricky because most of the documentation is standard Apache documentation, not based on Debian's more complex setup. Here are the solutions we found.

Enabling virtual hosts

As soon as the new apache 2.2.9 was running, we lost all our websites, because the virtual hosts that had worked fine on Etch broke under Lenny's 2.2.9. Plus, every restart complained [warn] NameVirtualHost *:80 has no VirtualHosts.

All the web documentation said that we had to change the <VirtualHost *> lines to <VirtualHost *:80>. But that didn't help. Most documentation also said we would also need the line: NameVirtualHost *:80 Usually people seemed to find it worked best to put that in a newly created file called conf.d/virtualhosts. Our Lenny upgrade had already created that line and put it in ports.conf, but it didn't work either there or in conf.d/virtualhosts.

It turned out the key was to remove the NameVirtualHost *:80 line from ports.conf, and add it in sites-available/default. Removing it from ports was the important step: if it was in ports.conf at all, then it didn't matter if it was also in the default virtual host.

Enabling CGI scripts

Another problem to track down: CGI scripts had stopped working. I knew about Options +ExecCGI, but adding it wasn't helping. Turned out it also needed an AddHandler, which I don't remember having to add in recent versions on Ubuntu. I added this in the relevant virtual host file in sites-available:

  <Directory />
    AddHandler cgi-script .cgi
    Options ExecCGI
  </Directory>

Enabling .htaccess

We have one enduring mystery: .htaccess files work without needing a line like AllowOverride FileInfo anywhere. I've needed to add that directive in Ubuntu-based apache2 installations, but Lenny seems to allow .htaccess without any override for it. I'm still not sure why it works. It's not supposed to. But hey, without a few mysteries, computers would be boring, right?

Tags: web, apache, debian
[ 20:46 Jul 05, 2010    More tech/web | permalink to this entry ]

Use Firefox User CSS to make LinkedIn discussions scroll normally

Several groups I'm in insist on using LinkedIn for discussions, instead of a mailing list. No idea why -- it's so much harder to use -- but for some reason that's where the community went.

Which is fine except for happens just about every time I try to view a discussion: I get a notice of a thread that sounds interesting, click on the link to view it, read the first posting, hit the space bar to scroll down ... whoops! Focus was in that silly search field at the top right of the page, so it won't scroll.

It's even more fun if I've already scrolled down a bit with the mousewheel -- in that case, hitting spacebar jumps back up to the top of the page, losing any context I have as well as making me click in the page before I can actually scroll.

Setting focus to search fields is a good thing on some pages. Google does it, which makes terrific sense -- if you go to google.com, your main purpose is to type something in that search box.

It doesn't, however, make sense on a page whose purpose is to let people read through a long discussion thread.

Since I never use that search field anyway, though, I came up with a solution using Firefox's user css. It seems there's no way to make an input field un-focusable or read-only using pure CSS (of course, you could use Javascript and Greasemonkey for that); but as long as you don't need to use it, you can make it disappear entirely.

Add this line to chrome/userContent.css inside your Firefox profile (create it if it doesn't already exist):

form#global-search span#autocomplete-container input#main-search-box {
  visibility:hidden;
}

Then restart Firefox and load a discussion page. The search box should be hidden, and spacebar should scroll the page just like it does on most web pages.

Of course, this will need to be updated the next time LinkedIn changes their page layout. And it's vaguely possible that somewhere else on the web is a page with that hierarchy of element names. But that's easy enough to fix: run a View Page Source on the LinkedIn page and add another level or two to the CSS rule. The concept is the important thing.

Tags: html, web, css, tips, annoyances
[ 16:17 Jun 25, 2010    More tech/web | permalink to this entry ]

Scaling HTML slides for different projectors with full-page zoom

Regular readers probably know that I use HTML for the slides in my talks, and I present them either with Firefox in fullscreen mode, or with my own Python preso tool based on webkit.

Most of the time it works great. But there's one situation that's always been hard to deal with: low-resolution projectors. Most modern projectors are 1024x768, and have been for quite a few years, so that's how I set up my slides. And then I get asked to give a talk at a school, or local astronomy club, or some other group that has a 10-year-old projector that can only handle 800x600. Of course, you never find out about this ahead of time, only when you plug in right before the talk. Disaster!

Wait -- before you object that HTML pages shouldn't use pixel values and should work regardless of the user's browser window size: I completely agree with you. I don't specify absolute font sizes or absolute positioning on web pages -- no one should. But presentation slides are different: they're designed for a controlled environment where everyone sees the same thing using the same software and hardware.

I can maintain a separate stylesheet -- that works for making the font size smaller but it doesn't address the problem of pictures too large to fit (and we all like to use lots of pictures in presentations, right?) I can maintain two separate copies of the slides for the two sizes, but that's a lot of extra work and they're bound to get out of sync.

Here's a solution I should have thought of years ago: full-page zoom. Most major browsers have offered that capability for years, so the only trick is figuring out how to specify it in the slides.

IE and the Webkit browsers (Safari, Konqueror, etc.) offer a wonderful CSS property called zoom. It works like this:

body {
  zoom: 78.125%;
}

78.125% is the ratio between an 800-pixel projector and a 1024-pixel one. Just add this line, and your whole page will be scaled down to the right size. Lovely!

Lovely, except it doesn't work on Firefox (bug 390936). Fortunately, Firefox has another solution: the more general and not yet standardized CSS transform, which Mozilla has implemented as the Mozilla-specific property -moz-transform. So add these lines:

body {
  position: absolute; left: 0px; top: 0px;
  -moz-transform: scale(.78125, .78125);
}

The position: absolute is needed because when Firefox scales with -moz-transform, it also centers whatever it scaled, so the slide ends up in the top center of the screen. On my laptop, at least, it's the upper left part of the screen that gets sent to the projector, so slides must start in the upper left corner.

The good news is that these directives don't conflict; you can put both zoom and -moz-transform in the same rule and things will work fine. So I've added this to the body rule in my slides.css:

  /* If you get stuck on an 800x600 projector, use these:
  zoom: 78.125%;
  position: absolute; left: 0px; top: 0px;
  -moz-transform: scale(.78125, .78125);
   */

Uncomment in case of emergency and all will be well. (Unless you use Opera, which doesn't seem to understand either version.)

Tags: speaking, html, css, browsers, firefox, mozilla
[ 11:14 Jun 20, 2010    More tech/web | permalink to this entry ]

Firefox printer preferences: the novel

I discovered recently that 1067 lines in my Firefox preferences file (out of 1438 total) were devoted to duplicating default printer settings.

I got a new printer recently. I needed to set up a preference in user.js so I can switch temporarily to landscape mode printing without having landscape mode become permanent. So I checked in on prefs.js to see what Firefox called my new printer -- and, well, eek!

For every printer I've ever used on this machine, I had a set of options that looked like this:

user_pref("print.printer_Epson.print_bgcolor", false);
user_pref("print.printer_Epson.print_bgimages", false);
user_pref("print.printer_Epson.print_colorspace", "default");
user_pref("print.printer_Epson.print_command", "lpr ${MOZ_PRINTER_NAME:+-P\"$MOZ_PRINTER_NAME\"}");
user_pref("print.printer_Epson.print_margin_bottom", "0.500000012107193");
user_pref("print.printer_Epson.print_margin_left", "0.500000012107193");

and so on -- 41 lines, in the case of print.printer_Epson. But some printers had multiple sets of preferences -- here's the list of printer names, each of which had those 41 lines, more or less:

• printer_Brother
• printer_CUPS/Brother
• printer_CUPS/Epson
• printer_CUPS/epson
• printer_Epson
• printer_PostScript/default
• printer_Print_to_File
• printer_Deskjet-F4200-series
• printer_HP_Deskjet_F4200_series

In case you're curious, this encompasses three physical printers I've used with Firefox: my old Epson C86, my new HP F4280, and Dave's Brother HL 2070N. None of these values is anything I've ever set myself; they're all default values.

Why Firefox feels the need to store them for all eternity is anybody's guess.

But wait, you say ... 41 lines times 9 printers is a lot, but it doesn't come close to equalling 1067 lines. What else is there?

Well, there are another 43 lines that repeat all those same defaults again but don't specify any particular printer, like user_pref("print.print_footerleft", "&PT");.

And then, oh wait, what's this? All the preceding prefs are duplicated all over again, with "tmp" added, like this:

user_pref("print.tmp.printerfeatures.Brother_HL-2070N_series.supports_paper_size
_change", true);
user_pref("print.tmp.printerfeatures.CUPS/Brother.orientation.count", 2);

and so on. 456 lines of that.

Unfortunately, I got a little over-zealous in deleting lines before I'd made a backup of the original file. So by the time it occurred to me to write this up, I'd destroyed some of the evidence and had to work from a backup, which "only" had 813 lines of print preferences. Part of that is that I didn't have the new printer yet (two entries times 41 lines times two) but that only gets me up to 977 lines. I'm not sure what the other 190 lines were.

How many printing preferences do you have? You can see them by going to about:config and typing print. Or on Linux, you can count them. First find your profile folder, where your prefs.js file lives, or search for prefs.js directly:

locate prefs.js | grep home

Then use wc on that prefs.js file to count your print preference lines:

grep print yourprofile/prefs.js | wc -l

As to why Firefox uses so many redundant lines in the preference file for settings that have never been changed from the defaults ... well, your guess is as good as mine.

Tags: firefox, mozilla, preferences, printing
[ 18:59 Mar 19, 2010    More tech/web | permalink to this entry ]

"Cookies are small text files" -- what?

"Cookies are small text files which websites place on a visitor's computer."

I've seen this exact phrase hundreds of times, most recently on a site that should know better, The Register.

I'm dying to know who started this ridiculous non-explanation, and why they decided to explain cookies using an implementation detail from one browser -- at least, I'm guessing IE must implement cookies using separate small files, or must have done so at one point. Firefox stores them all in one file, previously a flat file and now an sqlite database.

How many users who don't know what a cookie is do know what a "text file" is? No, really, I'm serious. If you're a geek, go ask a few non-geeks what a text file is and how it differs from other files. Ask them what they'd use to view or edit a text file. Hint: if they say "Microsoft Word" or "Open Office", they don't know.

And what exactly makes a cookie file "text" anyway? In Firefox, cookies.sqlite is most definitely not a "text file" -- it's full of unprintable characters. But even if IE stores cookies using printable characters -- have you tried to read your cookies? I just went and looked at mine, and most of them looked something like this:

Name: __utma
Value: 76673194.4936867407419370000.1243964826.1243871526.1243872726.2

I don't know about you, but I don't spend a lot of time reading text that looks like that.

Why not skip the implementation details entirely, and just tell users what cookies are? Users don't care if they're stored in one file or many, or what character set is used. How about this?

Cookies are small pieces of data which your web browser stores at the request of certain web sites.

I don't know who started this meme or why people keep copying it without stopping to think. But I smell a Fox Terrier. That was Stephen Jay Gould's example of a factoid invented by one writer and blindly copied by all who come later, (the fox terrier -- and no other breed -- was used for years to describe the size of Eohippus). At least that one was reasonably close. Gould went on to describe many more examples where people copied the wrong information, each successive textbook copying the last with no one ever going back to the source to check the information. It's usually a sign that the writer doesn't really understand what they're writing. Surely copying the phrase everyone else uses must be safe!

Tags: web, browsers, writing, skepticism, tech, firefox, mozilla
[ 20:25 Dec 01, 2009    More tech/web | permalink to this entry ]

Debug logging in Javascript under Firefox

While debugging Javascript, I've occasionally come across references to a useful function called console.log. Supposedly you can log errors with a line like:

  console.log(""key press, char code " + e.charCode);

Since the only native way of logging debug statements in Javascript is with a pop-up alert() box, having a less obtrusive way to print is something any JS programmer could use.

The catch? It didn't do anything -- except print console is not defined.

Today a friend was crowing about how wonderful Javascript debugging was in Google's Chrome browser -- because it has functions like console.log.

After some searching and poking around, we determined that Firefox also has console.log -- it's just well hidden and a bit hard to get going.

First, you need the Firebug extension. If you're developing Javascript, you probably already have it. If not, you need it.

Run Firebug and click to the Console tab. Now click on the tiny arrow that shows up at the right edge of that tab, as shown. Turns out there's a whole menu of options under there -- one of which is Enabled.

But wait, that's not all. In my case, the console was already Enabled according to the menu. To get the console working, I had to

1. Disable the console
2. Re-enable it
3. Shift-reload the page being debugged

My friend also said that if she didn't enable the console in Firebug, then her script died when she called console.log. That didn't happen for me -- all that happened was that I got error messages in the error console (the one accessed from Firefox's Tools menu, different from the Firebug console). But it's a good idea to check for its existence if you're going to use debugging statements in your code. Like this:

  if (typeof console != "undefined") {
    console.log( "key press, char code " + e.charCode
                + ", key code " + e.keyCode
                + ", " + e.ctrlKey + ", " + e.altKey
		+ ", " + e.metaKey );
  }

Here are some more things you can do with Firebug's console.

Tags: firefox, javascript, programming, tips
[ 15:41 Nov 28, 2009    More tech/web | permalink to this entry ]

Google UI Guinea Pigs

A friend wanted help figuring out why suddenly she was seeing a different Google page -- one with a logo that was less 3-dimensional, no drop shadow, and the search text field was in difficult-to-read colors. It was only on one machine, and nobody else she knew was seeing this new page. Was this some sort of Firefox bug? Did I know how she could get back to the old, easier to read Google page?

Fortunately she knew about Firefox's "View page info" menu item (right-click on the page to get it) and used the Media tab there to discover that the logo she was seeing was: http://www.google.com/images/srpr/logo1w.png.

Asking around and googling for things like google logo change or google different search page got me nowhere. It wasn't anything to do with disabling cookies or Javascript -- I tried turning those both off but still didn't see the page she saw (though turning off JS did get rid of the annoying fade-in effect Google started using recently).

Running out of ideas, I Googled for the filename of the logo she was seeing: google logo "logo1w.png" and that turned out to be the answer. I found discussions on reddit and NeoGAF, which led me to articles on SE Roundtable and search Engine Land comparing Google's UI to jazz (you never know what you're going to get next).

Following links eventually led me to an article on the official Googlblog, explaining how Google chooses random users as guinea pigs for trying out new user interfaces.

Unfortunately, none of these articles gave a clue how my friend could opt out of being a guinea pig and get back to a page where the search box colors didn't hurt her eyes.

But it turned out that it's cookie based. So if you find yourself stuck with a Google test page you don't like: Delete all your Google cookies. That did the trick for my friend, and got her back the standard interface.

The Googleblog article (which is full of interesting facts, as Googleblog articles often are) also led me to suggest another tip to her. Apparently a lot of this UI testing is based on how long it takes users to type their query into the search bar. So if you get selected as a test subject and you really dislike the UI they're showing you, typing very slowly might be a way to make it clear that this UI is not working out for you.

Tags: google, user interface
[ 15:03 Nov 24, 2009    More tech/web | permalink to this entry ]

A Pair of URL-Shortening Bookmarklets

I'm not a big fan of URL-shortening services -- I like to see what page I'm about to load so I know if I want to go there. But with Twitter's 160-character limit, URL shorteners become necessary. It's tiresome to type in bit.ly every time, so I wanted a bookmark to say "give me a shortened version of the current URL".

Surprisingly, I had a hard time finding one. bit.ly itself has one on their front page, but it didn't work for me. Upon examination, it looks like their bookmark wants to read the clipboard, so you'd have to select a URL first before shortening it (though they don't actually tell you that). I don't want that extra step, so I made my own. Actually two of them.

First, a Javascript version that takes the current URL, encodes it and sends it to bit.ly. I gave it the keyword "bitly", so when I'm on a page, I just type "bitly" in the URLbar and it goes to bit.ly and makes the shortened URL.

The only problem with that is that I'd rather have the option of opening it in a new tab, so I can continue to read the original page. Normally I open new tabs by typing in a URL and typing Ctrl-Return (normally it's Alt-Return in Firefox, but it drives me nuts that Firefox uses Ctrl-click for new tab but Alt-Return and I can never keep them straight, and Firefox's normal behavior for Ctrl-Return is brain-dead useless so that's the first thing I fix when I get a Firefox update).

With this bitly bookmarklet, Ctrl-Return and Alt-Return don't work -- because then you lose the original tab's URL, and bitly gives you a shortened URL to nowhere ... "nowhere" being defined, in the bitly universe, as http://about.com (go figure). What to do?

So I made a second bookmarklet using a different technique: instead of using Javascript to get the current page's URL, call the bookmarklet with the URL as argument. I called this one bitly2. So if I'm pointing at http://shallowsky.com/blog/ and I want a shortened version in a new tab, I type:

Ctrl-L to go to the URLbar
Ctrl-A to go to the beginning of the URL
bitly2 and a space (inserted at the beginning before the URL)
so now I'll see bitly2 http://shallowsky.com/blog/
Ctrl-Return (or Alt-Return) to open in a new tab.

I'm not sure which one I'll end up using more, but I'll obviously change the bitly2 name to something better if I end up using it a lot.

If you want to use either of these bookmarklets: right-click on the link and choose Bookmark this link. Then, alas, since Firefox still doesn't let you enter a keyword in its Bookmarks dialog, you have to go to Bookmarks->Organize Bookmarks, find the bookmarklet you just added and click on it, click on More, and finally you can give it a keyword.

There used to be a Firefox extension called Openbook that let you see the Keyword field when you first add a bookmark, but it doesn't work any more in 3.5, alas. There's another extension called "Add Bookmark Here 2" that's supposed to do it, but the file on addons.mozilla.org is apparently corrupted and won't install. I don't understand why the Firefox crew is so obsessed with bookmark tags (for which I've never found any use) but won't let you add something as truly useful as a keyword. (It's bug 242834, marked WONTFIX.)

Of course, after I had my bookmarklets I finally found a page with a decent bit.ly bookmarklet very similar to my first one: A Quick Tutorial on JavaScript Bookmarklets.

Tags: bookmarklets, twitter, javascript
[ 14:34 Aug 18, 2009    More tech/web | permalink to this entry ]