Lighthouse Users

Comments and changes to this ticket

• 

  Will May 5th, 2008 @ 11:49 PM

  • → State changed from “new” to “open”

  can you please attach the image onto this ticket? or try to? if it doesnt work, email it to company@activereload.net

• 

  jeromio May 6th, 2008 @ 09:38 AM

  I tried again today on a Winders machine (last night was Linux). It worked. However, there is an extra thing that I noticed. Last night there was an entry in the 1st password field, but not the second. If I left that, then I would get an error. So my natural response was to fill in the 2nd passwd box. I wonder if the form is taking a password update (to the same password) and ignoring the image upload? Today on the winxp box (ff2, the linux is kubuntu 8 w/ ff3b5), both passwd fields were blank (which is probably as it should be).

  Also, even though it did work this time, there was no immediate feedback. I was taken back to the profile page and the default icon was still there - as if my photo did not get uploaded. It was only when I clicked on this ticket that the change in profile photo became noticeable.

  So I think there are still 3 issues:

  • if passwd is changed, photo upload is ignored
  • sometimes (at least in linux ff3b5) the top passwd field has an entry when it probably should not
  • profile photo change is not immediately noticeable
• 

  jeromio May 6th, 2008 @ 09:42 AM

  More info: My profile photo is only set when I'm here in the activereload area of lighthouse. When I go to insoshi.lighthouseapp.com, the profile photo is NOT set. I tried to set it, but it doesn't change. As soon as I go back here to activereload.lighthouseapp.com, the profile photo is back.

  BTW, the profile edit dialog in the insoshi area is the same in terms of the blank passwd change fields (I'm still on the winxp ff2 client).

• 

  rick May 6th, 2008 @ 10:45 AM

  So I think there are still 3 issues:

  - if passwd is changed, photo upload is ignored

  - sometimes (at least in linux ff3b5) the top passwd field has an entry when it probably should not

  - profile photo change is not immediately noticeable

  The password/avatar issue is definitely a little bug that needs to be fixed.

  As far as the photo change not being immediately noticeable, that's an

  artifact of the caching system. All of the avatars link to a unique

  ID, not a filename so that if someone changes their avatar from

  'spongebob.jpg' to 'patrick.jpg', it doesn't invalidate all cached

  instances of the avatar throughout the whole app. Rather than go

  through and invalidate all of the cached data over a silly avatar, I

  use some custom rewrite routes so that the path never actually

  changes. I may have to look into some custom headers I can send back

  so the browser knows to refresh the URL.

• 

  rick June 17th, 2008 @ 01:20 AM

  I can't duplicate this problem on staging. Looking at the code, I see no reason why it should ever ignore the avatar upload, unless there's a problem processing the image. That process definitely could be tweaked so that errors are handled better, though.

• 

  Will June 25th, 2008 @ 10:29 PM

  • → Tag changed from “” to “account profile”
  • → State changed from “open” to “resolved”

  This is fixed now. I tested with random sizes of jpg and png files, all seems to be working fine.

  There is a cache delay after the upload is confirmed, when you refresh your browser you will see the change.