closing my laptop lid at the gdm prompt doesn't work normally

This is tested with the Preview release of Breezy

Also discovered just now that the same problem occurs when I'm in console mode
in one of the VTs.

is this bug a duplicate of bug #30949 ? They appear to be related.

Still occuring with Dapper Flight 7 + daily updates. But at least now if I do a ctrl-alt-backspace to restart X, I get the display back. That's an improvement from Breezy when the only way to get the display back was a reboot.

Thank you for taking the time to report this bug and helping to make Ubuntu better.
I am a bug triager making sure bug have all needed information.
Assigning package acpi-support rather than Ubuntu.
Because this have been a long time since last comment on this bug:
Is it still an issue with more recent version?
If you have a fast Internet connection, trying with Gutsy Tribe-2 would be great.
See: http://www.ubuntu.com/testing/tribe2

This is still a problem with both Feisty and Gutsy. Gutsy is up to date with all the latest packages...which I guess is currently slightly newer than Tribe 2. If this problem is related to Bug #30949, then it appears is due to a Dell BIOS bug.

Moving the status from 'Incomplete' to 'Confirmed'.

http://konsistent.de/wiki/doku.php?id=public:latitude110l says:
  -Warning: vbetool needed to reactivate display after lid close
  -Never close the lid if you don’t have vbetool installed. The display will be deactivated and you may only reactivate it with X.org < 6.8.99 running (switch to console).
  -I searched long for a solution and - surprise surprise - have found one. It’s a kernel bug. Just emerge vbetool and execute the following script when the OS receives an ACPI lid event:
#!/bin/sh

if [[ ! `grep open /proc/acpi/button/lid/*/state` = "" ]]
then
    logger "ACPI lid opened. Reactivating display.";
    /usr/sbin/vbetool dpms on
else
    logger "ACPI lid closed.";
fi

To react on the lid event put this at the appropriate place into your /etc/acpi/default.sh:

lid) /etc/acpi/actions/lid.sh
    ;;

Preceding comment is about a guy using Gentoo, not Ubuntu.
Unless you are pretty at ease with this kind of stuff, you should probably wait package maintainer opinion.

Also, giving the usual information should help.

Typing the following in a Terminal (console) [after the bug happened]:
cd
mkdir bug21440
cd bug 21440
uname -a > DR_uname.txt
lspci -vvnn > DR_lspci.txt
lsmod > DR_lsmod.txt
cat /etc/default/acpi-support > DR_etc_default_support.txt
dmesg > DR_dmesg.txt

And then attaching each of the file in the bug21440 directory inside your home directory to this bug report, should help
better diagnose the problem.

Thank you for taking time to report bugs and making Ubuntu better!

It's nice to see that this 2-year old laptop, a member of the original Canonical's Ubuntu Laptop Testing Team, can still be of use to try to solve a bug in Ubuntu :)

So here is the info you requested.

Output of uname -a

Output of lspci -vvnn

Output of lsmod

Content of /etc/default/acpi-support

Output of dmesg

Thanks for giving all this info so fast! Now, let's wait for maintainer to take a look at all this information.

Bug #44393 (incomplete for now) looks very similar (in GDM only, on a Dell too).

You may want to add debugging lines into /etc/acpi/lid.sh to see what's going on, e.g.
LIDLOG=/var/log/lid.sh.log
echo "$(date): called lid.sh" >> $LIDLOG
echo "$(date): state $(cat /proc/acpi/button/lid/*/state)" >> $LIDLOG

In bug 44393 there was mentioned that this was caused by a broken DSDT on a Dell Inspiron 6400/1505 (https://bugs.edge.launchpad.net/ubuntu/+source/acpi-support/+bug/44393/comments/9)

Please also test, if this is fixed with Hardy already.
Thank you.

Totally forgot about this bug. It is now fixed in Hardy.