304863 - Image onLoad event handler does not function.

Status: RESOLVED WORKSFORME

(SeaMonkey :: General, defect)

Description

[vickery]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728

The problem URL works for Firefox 1.0.6, IE6, Opera 8.02, and Netscape 8.01, but
not from the Mozilla 1.7.11 browser; all tested from Windows XP.  I have also
seen the problem with Listing 20-4 of Danny Goodman's "Javascript Bible, Fifth
Edition."

The Javascript code hides an image being displayed in a img tag, creates an
Image object, assigns a URL to the object's src field, then (tries to) set up an
event handler to be invoked when the new image has been loaded.  (The event
handler adjusts the size of the displayed image and then makes it visible.)  But
the event handler never gets called when accessing the page using Mozilla 1.7.11
(or earlier.)  The code that works for all other browsers is "theImage.onload =
finishDisplayingImage;"  I tried various forms of addEventListener and even
attachEvent to no avail.  I couldn't figure out whether the event handler
doesn't get registered or just doesn't get called.


Reproducible: Always

Steps to Reproduce:
1.  Access the problem URL.
2.  Observe the displayed page
3.

Actual Results:  
An image is displaye briefly, then disappears. (You might not see it flash by.)

Expected Results:  
There should be a picture of some flowers, centered and filling most of the
viewport.  Clicking the Next button should display another image, but it doesn't
get displayed either.


I'll attach the three source code files (index.php, photos.css, and photos.js)
to the bug report.  The code mentioned above is in the function "displayImage"
near the beginning of photos.js.

Comment 1

[vickery]

Attachment: Javascript including function "displayImage"

The functions that demonstrate the error are the first two in the file. 
displayImage() tries to set up the event handler; finishDisplayingImage() is
the event handler itself that never gets called.

Comment 2

[vickery]

Attachment: Web page that causes the problem

Requires PHP to run ...

Comment 3

[vickery]

Attachment: Style sheet for problem URL

Comment 4

[Gérard Talbot]

attachment 12397 [details] WORKSFORME
Seamonkey 1.0a rv:1.9a1 build 2005081505 under XP Pro SP2 here.

-------

vickery: 
- attachment 192850 [details] has problems and is not correct, not usable.
- the URL should end with a forward slash. I've made the correction.
- there is no onload event handler for any image anywhere in your code.

I've examined the http://babbage.cs.qc.edu/BC/photos.js code

I doubt there is a problem with Mozilla here; I can try other sites using a
slideshow of pictures. Besides delay of fetching, internet traffic and loading
the referenced image over the network, I don't see anything *major* clearly
wrong or troublesome in your code or when trying the
http://babbage.cs.qc.edu/BC/ page. So far, I've seen several images of beautiful
flowers and nature sites at http://babbage.cs.qc.edu/BC/; up to DSCN2819.jpg
548px wide by 411 px high. Seamonkey 1.0a rv:1.9a1 build 2005081505 under XP Pro
SP2 here. You have to remember that such photos can take several seconds to be
fetched, downloaded, processed by your functions and then be rendered.

In your finishDisplayingImage function,
    imgTag.style.width      = newWidth  + "px";
    imgTag.style.height     = newHeight + "px";
your code does not make sure newWidth and newHeight are integer values.

The geometryChanged() function works as intended when I resize the viewport.

-------

Just for your info, the javascript console reports 6 assignments to undeclared
(global) variables. Your code could be simplified or optimized further and
tweaked at a few areas here or there.

Comment 5

[Gérard Talbot]

Ok. There is an onload event handler for the image... in the middle/among
several comments in your code (around line 34). 
I examined your photo.js file with breakpoints with Venkman javascript debugger
and watched local variable values (imageAspectRatio, viewportAspectRatio,
newWidth, newHeight). Your displayFinishingImage code which does resizing of
wrapping div and image. Venkman js debugger sees that the values are real and
not integer. Besides that, I see nothing wrong and venkman js debugger reports
nothing abnormal.

Btw, there is no need to size the div at all. Best is to simply set the img to
text-align: center and let the div take as wide as the viewport. There is no
need to center the wrapping div ("imgDiv") with margin-left: auto; and
margin-right: auto; if that wrapping div ("imgDiv") does not take, does not uses
a specified width. Same thing with resizing that wrapping div ("imgDiv"): there
is no need to set its width actually.

Comment 6

[vickery]

Thanks for looking at my code so carefully.  I fixed the undeclared globals and
the floating-point values for height and width, and the problem persists for me.
I'm running under XP with SP1 but not SP2.  Sorry, but I'm not sure how
Seamonkey relates to Mozilla/Firefox/Navigator.  I have no problem with the code
using Firefox and/or Navigator, only Mozilla.  And only from XP; when I use
Mozilla 1.7.8 on Debian Linux, there is no problem.

But if you can't reproduce the problem using the Mozilla browser on Windows XP,
well that's a problem in itself!

(And I can't figure out why I never see anything about undeclared globals on my
Javascript console -- either Windows or Linux side. But that's another matter, I
guess.)

Comment 7

[Gérard Talbot]

> Thanks for looking at my code so carefully.  I fixed the undeclared globals and
> the floating-point values for height and width, and the problem persists for me.

I would reduce the number of colors in your image; this is a frequent technique
to reduce file size of images without compromising quality of images. The gain
is usually at least 25%. This gain can be greater when using .png instead of
.jpg: better compression. When trying your page, images took ~10 sec. each
time... when images were over 80KB.

> I'm running under XP with SP1 but not SP2.  Sorry, but I'm not sure how
> Seamonkey relates to Mozilla/Firefox/Navigator. 

Seamonkey is the replacement, continuation (or new name, if you prefer) of
Mozilla Suite.
Can you try your webpage with the latest trunk build:
http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-trunk/

> I have no problem with the code
> using Firefox and/or Navigator, only Mozilla. 

Well, then, that is good news, I'd say.

> And only from XP; when I use
> Mozilla 1.7.8 on Debian Linux, there is no problem.
> 
> But if you can't reproduce the problem using the Mozilla browser on Windows XP,
> well that's a problem in itself!

You're using rv:1.7.11 build 20050728. I was using rv:1.9a1 build 2005081505. It
still could be a confirmable bug... but on/for the 1.7 branch.
 
> (And I can't figure out why I never see anything about undeclared globals on my
> Javascript console -- either Windows or Linux side. But that's another matter, I
> guess.)
 

Try this to set strict warnings. 
about:config 
and then search for 
javascript.options.strict
and then set it to true.
In Seamonkey trunk build:
Edit/Preferences.../Debug category/Miscellaneous/Show strict javascript warnings

Also, starting from 1.8alpha 4, the js console also reports CSS parsing
errors... which is excellent.

Comment 8

[vickery]

Greetings from SeaMonkey 1.0a running on Windows XP SP1!

At the URL babbage.cs.qc.edu/BC, I have copied the Thumbs directory over the
Images directory so you won't have to wait so long for images to load.  (There
is a user option for selecting image resolution in a later version of the code
...) My apologies for the eyestrain of looking at the blurriness due to upsizing
thumbnails to the size of "images."  But it saves time.

The bad (?) news is that The problem still exists when using this version of
SeaMonkey: the onload callback for an img never gets called, with the net effect
that no image ever gets displayed once the page loads.

Where to go from here?

Comment 9

[vickery]

... and thanks for pointing me to the javascript.strict option; that's already
speeding things up on the current version of the code ...

Comment 10

[Gérard Talbot]

> The bad (?) news is that The problem still exists when using this version of
SeaMonkey

Can you confirm/make sure that you have in your about:config
dom.disable_image_src_set
set to false
and/or in Mozilla Suite:
Edit/Preferences.../Advanced category/Scripts & plugins/Allow scripts to: Change
images checkbox checked

Comment 11

[Gérard Talbot]

> The bad (?) news is that The problem still exists when using this version of
> SeaMonkey

What's the build number of that version of Seamonkey?
Can you try with a brand new profile with the latest Seamonkey?... and make sure
that 
dom.disable_image_src_set
is set to false
and/or in Mozilla Suite:
Edit/Preferences.../Advanced category/Scripts & plugins/Allow scripts to: Change
images checkbox checked

With a new profile, I'd be surprise if you still have that loading image problem...

Do you use some kind of extensions which may/could interfere with your script
and cause possible problems? With a new profile, make sure you have no extension
loaded. 
Do you have 
Resize large images to fit into the browser window
checkbox checked?
Edit/Preferences.../Appareance category
Your "Resize large images to fit into the browser window" setting whatever it
may be should not interfere with your script.

One last thing. The default type value for button is submit, not button and
Mozilla complies with the spec on this. But again, that shouldn't interfere anyway.

Comment 12

[vickery]

Bingo! (Or, Blush!!)
The change images checkbox was clear, and checking it resolved the issue.  So
your other comments, about button types and the browser-resize-images option
become moot, as you suggested anyway.  I think I must have unchecked the
scripting restriction when Mozilla was my default browser a couple of years ago,
and I guess that profile got picked up when I installed the current versions of
Mozilla and SeaMonkey.

I assume the proper resolution of this is "invalid" -- but will leave it for you
to change, if you don't mind, as I'm not certain.

Many, many thanks for your work on this, and sincere apologies for my posting a
non-issue here.

Comment 13

[Gérard Talbot]

> I assume the proper resolution of this is "invalid" -- but will leave it for you
> to change, if you don't mind, as I'm not certain.

"In general you can resolve a bug as WFM if: (...) the bug reporter reports that
he can no longer see the bug"
http://www.mozilla.org/quality/help/bugzilla-privilege-guide.html#resolving

I would warn Mozilla visitors when viewing your page to have javascript and that
setting enabled.

>Many, many thanks for your work on this
No problem. Glad I could help. :)