364850 - Stale image properties after image reload

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, defect)

Description

[Nick Weavers]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1

If you have a web page that displays an image on a web page using <img id="myimg" src="myurl">, and some javascript that first uploads a new different size image to "myurl" using XMLHttpRequest, then  then reloads the image using document.getElementById('imgJSselbox').src = rURL +    '?' + "uniquestring" to force a cache update, you will see the new image in the browser but the other image properties such as offsetLeft, offsetTop, offsetHeight and offsetWidth will all be those that relate to the old image and not the new one. 

Reproducible: Always

Steps to Reproduce:
If you have a web page that displays an image on a web page using <img id="myimg" src="myurl">, and some javascript that first uploads a new different size image to "myurl" using XMLHttpRequest, then  then reloads the image using document.getElementById('imgJSselbox').src = rURL +    '?' + "uniquestring" to force a cache update, you will see the new image in the browser but the other image properties such as offsetLeft, offsetTop, offsetHeight and offsetWidth will all be those that relate to the old image and not the new one. 
Actual Results:  
offsetLeft, offsetTop, offsetHeight and offsetWidth pertain to old image.

Expected Results:  
offsetLeft, offsetTop, offsetHeight and offsetWidth should pertain to the new image.

Without the correct values for offsetLeft, offsetTop, offsetHeight and offsetWidth it is impossible to determine the size or position of the new image and therefore to do anything such as overlay a cropping window aligned on the centre of it.

Comment 1

[Mats Palmgren (inactive)]

Attachment: Testcase #1

Does "Test2" in this testcase correspond to what you are trying to do?
FWIW, I don't consider our current behavior to be a bug. Changing 'src'
doesn't stop the script from executing and the result of 'offset*'
depends on how far the new image load has progressed.
If you want the correct the result I think you need to wait for the new image
load to finish, for example using 'onload' as demonstrated in "Test3".

Comment 2

[Nick Weavers]

Attachment: user testcase

This is the main page. I will attach the included php and javascript files seperately.

Comment 3

[Nick Weavers]

Attachment: drag_handler_mk2.js included by user testcase

The included javascript drag handler used in the user testcase.

Comment 4

[Nick Weavers]

Attachment: The store_image.php function called by the XMLHttpRequest in the user test case

The store_image.php function called by the XMLHttpRequest (inside YUI Connection Manager) by the user testcase.

Comment 5

[Nick Weavers]

Attachment: The crop_image.php function called by the XMLHttpRequest in the user test case

The crop_image.php function called by the XMLHttpRequest (inside YUI Connection Manager) by the user testcase

Comment 6

[Nick Weavers]

(In reply to comment #1)
"If you want the correct the result I think you need to wait for the new image
load to finish, for example using 'onload' as demonstrated in "Test3"."

This is correct. I replaced the code in my imageReload function with a call to your f2 function to see if it would correct my problem by making the reload synchronous but although the new image gets reloaded and shows in the browser, the  accompanying "After:" alert issued by f2b shows all of the image offset properties  to be undefined. 

Comment 7

[Mats Palmgren (inactive)]

Is the image visible at the time f2b runs? (in other words, does the image
and all its ancestors have display!=none).

Comment 8

[Nick Weavers]

(In reply to comment #7)
Yes, the new image is visible at the time f2b runs and can be seen behind the "After:" alert invoked by it showing that all of the offset properties are undefined.

Neither the visibility or the display properties of the image or its ancestors are ever changed. The only use of display properties is to hide or reveal different forms and the cropping overlay and instructions.

I also tried altering f2b as follows:

function f2b(event) {
  img = event.target
  window.setTimeout("alert(s('After:',img));",2000);
  return false;
}

and although it delayed the checking of the offset's for a couple of seconds they were still shown as undefined in the alert.

Comment 9

[Mats Palmgren (inactive)]

It would help if you could put your example code on a public server and/or
reduce it to a minimal testcase.

Comment 10

[Nick Weavers]

(In reply to comment #9)
I will do this tomorrow. 
Thanks and Merry Christmas. 

Comment 11

[Nick Weavers]

(In reply to comment #10)
Please try 
http://www.chasingmidnight.com/CMS/ff_tc2.php

Thanks

Comment 12

[Mats Palmgren (inactive)]

That URL seems to work for me, in the first alert I see the existing image
size (75x100), in the second alert I see the size of the uploaded image.
I tried uploading both a small and a large image.

Comment 13

[Nick Weavers]

Attachment: Screenshot

Screen shot showing second alert in firefox for the png file you uploaded.

Comment 14

[Nick Weavers]

(In reply to comment #13)
> Created an attachment (id=249719) [edit]
> Screenshot

This is a screen shot showing the second alert message when I upload a copy of the same png file that you uploaded. I am running "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1". 

I installed the latest nightly build to try my code against but it crashed before it finished opening. 

Comment 15

[Mats Palmgren (inactive)]

Sorry, I was using a trunk build for testing... I can reproduce
the problem in Firefox 2.0.0.1 on Linux.  Testing older builds from 
http://archive.mozilla.org/pub/firefox/nightly/ the problem goes away
between the builds 2006-03-07-05 -- 2006-03-08-08  (please confirm)
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-03-07+05%3A00&maxdate=2006-03-08+09%3A00&cvsroot=%2Fcvsroot
I would guess bug 234455.

Comment 16

[Nick Weavers]

(In reply to comment #15)
The closest builds for windows I could find were:

/pub/firefox/nightly/2006-03-07-05-aviary1.0.1
firefox-1.0.8.en-US.win32.installer.exe 07-Mar-2006 05:53  4.6M 
/pub/firefox/nightly/2006-03-08-12-aviary1.0.1
firefox-1.0.8.en-US.win32.installer.exe 08-Mar-2006 13:00  4.6M  

I'm afraid I don'y have a linux machine to test on. Do you want me to confirm against the windows versions shown above?

Comment 17

[Mats Palmgren (inactive)]

Yes, please, but you want trunk builds, not the aviary-1.0.1 builds. i.e.
http://archive.mozilla.org/pub/firefox/nightly/2006-03-07-05-trunk/
http://archive.mozilla.org/pub/firefox/nightly/2006-03-08-09-trunk/
It's probably less intrusive to use the .zip packages, just run Firefox from
the unzip folder. Make sure you close all other Firefox windows first. Thanks.

Comment 18

[Nick Weavers]

(In reply to comment #17)
I am finding both versions crash as soon as the upload button on my test page is clicked when I run firefox.exe fom the unzip folder.

I will uninstall my current version and install each properly before testing

Comment 19

[Nick Weavers]

(In reply to comment #17)
Sorry, I cannot get these ealier builds to run on my PC even after unistalling any existing version and then doing a full install of either nightly build.

I have now reinstalled 2.0.0.1 and rechecked. I still get the bug I have reported.

Comment 20

[Mats Palmgren (inactive)]

Ok, thanks for trying. It's probably due to some incompatible extension/plugin
on your system. I will test the Windows builds as well in a bit...

Comment 21

[Mats Palmgren (inactive)]

2006-03-07-05-trunk: "undefined" in the second alert
2006-03-08-09-trunk: correct width/height for the uploaded image
both on Windows Vista RC2

-> WORKSFORME

Comment 22

[Nick Weavers]

(In reply to comment #21)
So does this mean that Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1 works for you also, and what about your statement "I can reproduce
the problem in Firefox 2.0.0.1 on Linux."? Does that still stand?
 

Comment 23

[Mats Palmgren (inactive)]

No, it means 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.
To get it fixed on a branch someone needs to track down which checkin in
the range (see comment 15) that fixed it and then ask for approval for that
patch to land on the branch.
If I'm right that bug 234455 fixed this then it's very unlikely it will
be approved for branch checkin (this bug isn't severe enough for that
kind of risk). If I'm wrong and it's a simple low-risk fix then it's
probably going to be approved.
Either way, that procedure is handled on the bug that has the patch that
fixed it, not here.
Personally, I'm not going to track down which checkin fixed it, sorry.

Comment 24

[Nick Weavers]

(In reply to comment #23)
Where does that leave me? Is there somewhere else I can report this to get it fixed (against a Firefox team maybe)? I'll see if I can get some support from other users if it would help. I would think that with increasing use of "web 2.0" style design other people will hit this same problem at some stage.

Comment 25

[Mats Palmgren (inactive)]

The procedure to get this fixed in a future Firefox 2.* release is:
1. Find out which checkin fixed it (range in comment 15)
2. Ask on the corresponding bug that it be checked in on the 1.8 branch and
   motivate why it's important to fix, especially if the patch is big

Comment 26

[Nick Weavers]

(In reply to comment #25)
Okay, thanks for your help.