community website to upload a new picture of themselves. The upload
page shows the members current image if there is one or a silhouette
image if not. The page uses a form with enctype="multipart/form-data"
method="post" and a button of type="file" to allow the member to
browse to and select his/her new image. The upload is performed
without a page refresh using the excellent Connection Manager from the
Yahoo! User Interface Library.
When the user clicks the upload button the image is uploaded by the
connection manager and the uploadResponse callback invokes my response
function. If the uploaded image has simply been replaced, this
response function causes the image to be reloaded by reassigning it's
src property to the same url as before but with a '?' + now.getTime()
appended to ensure the browsers cached version is replaced.
So far so good, and I am gratified by seeing the image updated in
place. The next step is where I am seeing some behavior I didn't
expect. The remaining functions allow the uploaded image to be cropped
and involve using the images offsetLeft, offsetTop, offsetHeight and
offsetWidth to define a boundary inside which a 500px x 500px
translucent DHTML div can be dragged around as a cropping window.
What I think I am seeing is that although the assignment to the src
property causes the image to be reloaded, this doesn't seem to cause
the offsetLeft, offsetTop, offsetHeight and offsetWidth properties to
be updated. Can anyone tell me if this is what would be expected? If
so, is there any way in which I can also force them to be refreshed?
I have only tried this under Firefox so far as my code is peppered
with console.log messages which I don't want to remove yet and these
cause IE to barf (wish I done something like dbug - a console.log
Nick, Couple of things: 1. Joe Hewitt, Firebug s author, has a script you can include that will prevent console.log() errors in unsupported browsers; the codeMessage 1 of 7 , Dec 26 9:48 AMView SourceNick,Couple of things:1. Joe Hewitt, Firebug's author, has a script you can include that will prevent console.log() errors in unsupported browsers; the code for that script is here.2. I'm having trouble understanding exactly how the workflow progresses for the image cropping. Could you send a URL or some more information on that? Presumably, that refreshing is taking place as part of a Drag and Drop interaction?Regards,EricOn Dec 23, 2006, at 1:47 PM, Nick Weavers wrote:
Hi Eric, Thanks for taking a look at my post. I am working on a website that allows members to upload 4 images of themselves. They are stored in a directoryMessage 1 of 7 , Dec 27 3:15 PMView SourceHi Eric,
Thanks for taking a look at my post. I am working on a website that
allows members to upload 4 images of themselves. They are stored in a
directory under filenames that are made up of their numeric userid and
the number of the image. So, for a user with ID=68 his first picture
will be held in a file called say 68_1.jpg (it may be gif or png but
that info is held in a DB).
If user 68 wishes to replace his file he visits a page that shows his
current image and has a form to present the appropriate buttons and
functions on the page handle the asynchronous update using the
Connection Manager. This all seems to work nicely and the upload
response is called to refresh the image on the page by assigning the
original url to the images src property but with a '?' followed by a
random number appended to it to force a cache update.
Using Firefox 18.104.22.168 the image can be seen to change on the page but
the offset properties of the new image become undefined. The reason I
want those values is if necessary) to position a smaller cropping
window (div) at the centre of the user uploaded image and allow it to
be moved only within that image.
The problem can be reproduced at this test page
The page uses an alert popup to show the offset properties of the old
image (prior to the upload), and then those of the new image. If you
run the same page on either IE7 or Opera it works fine.
I raised this as a problem on Bugzilla where it was investigated and
reporduced (https://bugzilla.mozilla.org/show_bug.cgi?id=364850) but
then given a status of RESOLVED because "... the bug is not
reproducible on trunk. The bug still occurs on the 1.8 branch (Firefox
2.*). We don't generally keep bugs open unless they occur on trunk."
I am not sure where this leaves me in terms of getting it fixed.
I suspect it may be a problem to others wanting to do similar type of
things in the future...?
PS. Thanks for the firebug console disabling code.Message 1 of 7 , Dec 27 3:23 PMView SourcePS. Thanks for the firebug console disabling code.
Nick, Is it possible that you could get what you need by using a wrapper element? In other words, a div containing your image, if floated, will shrinkwrapMessage 1 of 7 , Dec 27 4:49 PMView SourceNick,Is it possible that you could get what you need by using a wrapper element? In other words, a div containing your image, if floated, will "shrinkwrap" around the image. You could use the Dom Collection to get the div's true page coordinates (YAHOO.util.Dom.getXY()) and the div's offsetHeight and offsetWidth properties may correctly update once the new image is in place.This sounds like a bug in Firefox, based on what your investigation turned up. But, in the meantime, a workaround like the one above might get you what you need?Regards,EricOn Dec 27, 2006, at 3:15 PM, Nick Weavers wrote:
Eric, The shrink wrap div sounds like a neat idea. I ll give it a go. Many thanks, Nick.Message 1 of 7 , Dec 27 5:00 PMView SourceEric,
The shrink wrap div sounds like a neat idea. I'll give it a go.
Hi Eric, just to let you know that the shrink-wrap div idea worked nicely as a workaraounf for the Forefox bug. Many thanks, Nick.Message 1 of 7 , Dec 30 8:10 AMView SourceHi Eric, just to let you know that the shrink-wrap div idea worked
nicely as a workaraounf for the Forefox bug.