Under /manage/logins, you can see your past login sessions, including the User-Agent string of the browser you were using at the time. However, a really long user-agent string(Hello, Google Chrome) gets cut off for some reason. Looking at the code, it calls up the string from the database table loginlog, column ua, which Googling revealed is probably limited by its type being VARCHAR(100). Which is really unfortunate, since most of the interesting version information seems to be at the end of the UA string these days. Mayhaps a switch to VARCHAR(200) is in order, to give it some breathing room.
grep'ing for where the database scheme might be set in the code(turns out, in update-db-general.pl) shows a few other fields with the same size:
./bin/upgrading/update-db-general.pl:921: subject VARCHAR(100) DEFAULT NULL, ./bin/upgrading/update-db-general.pl:2258: ua VARCHAR(100) ./bin/upgrading/update-db-general.pl:2291: class VARCHAR(100), ./bin/upgrading/update-db-general.pl:2301: class VARCHAR(100), ./bin/upgrading/update-db-general.pl:2404: class VARCHAR(100), ./bin/upgrading/update-db-general.pl:2756: handle VARCHAR(100) PRIMARY KEY, ./cgi-bin/LJ/AccessLogSink/Database.pm:79: "browser VARCHAR(100),". ./cgi-bin/LJ/AccessLogSink/Database.pm:80: "clientver VARCHAR(100),". ./cgi-bin/LJ/Error.pm:171: browser VARCHAR(100), ./cgi-bin/LJ/Error.pm:172: clientver VARCHAR(100)
Now I wonder how bad I can break my dreamhack if I just edit that Perl script to say VARCHAR(200) and run it...