Thursday, April 16, 2015

Encountered a bug where if a user uploads a photo, and then rotates the photo, and then rotates the photo again, the second rotation produces an error, but only if the user is not logged in.  After looking into this for a bit, I discovered that the rotation code checked if the photo was associated with a user, and if it was, it tried to access the user's info.  But if the user was not logged in, the code would produce an error.  The part that baffled me was why the photo was associated with a user when the user was not logged in.

After spending the better part of a day investigating this, I pieced together the workflow of the photo process:

1) Non-logged-in user uploads a photo.  The photo's info is saved to memory with no user associated with it.  The photo's info is then saved to the database.  However, for whatever reason, the database requires that a photo has an associated user, so a fake user is stored.

2) User rotates the photo.  The photo's info is retrieved from memory, which has no user associated with it.  Then the actual rotation occurs, and stuff is written to the database.  The photo's info is then retrieved from the database and written back to memory.  However, since the database has a fake user associated with the photo, that fake user is written to memory.

3) User rotates the photo again.  The photo's info is retrieved from memory, but this time, the photo is associated with a fake user.  Then the actual rotation occurs, but since this time the photo is associated with a fake user, the code tries to access the user's info, and since the user is not logged in, the code blows up.

Thursday, March 26, 2015

While removing Internet Explorer 7 and 8 hacks from our codebase, I encountered the following comments:

- DIE IE7 DIE DIE DIE
- without this, IE7 poops its pants
- IE6 goes missing on the hover state carat, I don't care
- what the hell is up with IE7 ???
- I had to set fixed width for boxes, otherwise IE7 freaks out. Bastard
- IE7 is fucking retarded
- IE7 is again playing the retard, causing lame parens and dashes to drop to the bottom of the container
- hate IE so much
- IE8 requires the following nonsense, naturally
- IE6 is not good software. One sign of this is that we need to set position absolute here to make this thing display in IE6
- IE6 throws a rubbery when it can't understand part of a compound selector (commas)
- but IE is retarded and thus we brute force it
- re-establish cache.mainImage, since IE is a retard
- IE 8 and below do not bubble change events, so lets hack the shit out of it :P
- inevitably, IE6 has to rain on our UTF parade ;_;