27365 - Image type displayed when viewing an image is not correct; it is just the image file's extension...

Status: RESOLVED FIXED

(Core :: Graphics: ImageLib, defect, P3)

Description

[Doron Rosenberg (IBM)]

If I view an image, it opens the new window, and the title of the new mozilla
window is "Image". In NS4.x, you get for example "JPEG image widthxheight"

This is with nightly build 2000020919.

Comment 1

[pnunn]

Nisheeth:
Looks like we ask for the w&h before the imagelib has
had a chance to decode the header. So both w & h are zero
and nothing displays when nsImageDocument::UpdateTitle() is called.

I'm passing this to you, but if you need my help, call.
-P

Comment 2

[Nisheeth Ranjan]

Re-assigning this Marc as per our conversation...

Comment 3

[Marc Attinasi]

Fixed. Changes in nsImageDocument.cpp: Moved the SetTitle call to the EndLayout 
method so the ImageLib has had a chance to get the size in all cases. Checkin 
pending review.

Comment 4

[Marc Attinasi]

Moved the UpdateTitle call to after the doc is loaded to ensure the dimensions 
have been determined. r=pnunn

Comment 5

[Eli Goldberg]

Re-opening on grounds that 4.x actually says image type (e.g. GIF or JPEG) and 
dimensions, whereas Seamonkey now only says dimensions.

(If you'd prefer that this be split off into a separate enhancement request, or 
punted on entirely, just re-resolve the bug with your comments. Thanks!)

Comment 6

[Eli Goldberg]

Oops.

Comment 7

[Doron Rosenberg (IBM)]

using 2000022708, no image size is shown.  Seems that something has happened.
Any idea as to why?

Comment 8

[Marc Attinasi]

I just checked it with a build made from sources pulled on 3/1 and it is still 
working (at least the size is being displayed: the file type is another story. I 
have changes to put the file extension in as the file type, however I want to 
use the MIME to get the file type instead, since we support arbitrary image 
formats that may have names other that are different from their extension).

I've changed the summary to reflect the part that still needs to be done.

Comment 9

[Doron Rosenberg (IBM)]

on win32 2000030308 build (m15 nightly), viewing image on top of this page has
only the text "Mozilla" in the header.  Also seen on m14 release

for example, http://www.thehungersite.com/images/site_TrusteFinalMark.gif

it loads fine, but in the console, get this: "Error loading URL
http://www.thehungersite.com/images/site_TrusteFinalMark.gif"

this was seen on linux and win32 (not just me).

however, viewing a image on the hardisk does show the image dimensions! attinasi
- can you view a non-local image and get it's dimensions?

Comment 10

[Marc Attinasi]

Yes, I can load the image fine over the net. The error you are getting loading 
the image may be a clue: the title and dimensions are set when the image is 
completed loading and the image loader notifies the ImageDocument. If there is 
an error loading the image it may not get called and hence no title. There have 
been times when the call was not being made (no notification from the image 
loader) so the title was not getting set, but this was fixed - unless it is 
broken again. 

It is working for me in my local build, and in the daily builds downloaded from 
Mozilla.org on 3/1 and todays daily dated 3/3, buildID 2000030313. Maybe you can 
try the most recent daily?

Comment 11

[Doron Rosenberg (IBM)]

Ok, here is what we found out after soem discussion over at #mozillazine:

Close all moz windows, open moz, and view
http://www.thehungersite.com/images/site_TrusteFinalMark.gif

This works.

now, open another window, and view the exact image. No one got the image
dimensions in the second window.

It seems that the header is not updated.  Whenever the image header is not
loaded, the header of the previous url is kept.

here is a test, seen on m14 and m15 - view the image in the first window, go to
other url (cnn.com), view image again, no dimensions, i get the old header (of cnn)

using http://www.thehungersite.com/images/site_TrusteFinalMark.gif as test image

Can you see this?  my guess is that the header is not updated when a image is
loaded after viewing another url.

Comment 12

[Marc Attinasi]

I see it (the problem) in the second window. The EndLayout callback is never 
being called so the title is never getting updated (nsImageDocument.cpp). 

Now I need to figure out why the EndLayout is not being called in a second 
window now... Thanks for all of the information on this one.

Comment 13

[Marc Attinasi]

The regression on the image dimensions not showing up (on a second window) has 
been fixed and is awaiting post-beta1 checkin. The image type is the part left 
to do.

Comment 14

[Doron Rosenberg (IBM)]

attinasi - everything seem to work in the new nightlies. Think this can be closed

Comment 15

[Marc Attinasi]

Thanks for the note: I'm going to reword the summary to reflect the fact that 
the Image Type is just the extension and not really the image type. 

This is only a problem if the image type does not correspond to the extension, 
and since we support arbitrary image types through loadable modules (I am told) 
this will not really be the correct behavior. It is not, however, very important 
at this time, so I'm also marking REMIND for post-beta (probably post Gecko 1) 
work.

Many thanks, doronr and elig for your help.

Comment 16

[Eli Goldberg]

Rubber-stamping as Verified/REMIND.

Comment 17

[Marc Attinasi]

Reopening to reclose...

Comment 18

[Marc Attinasi]

This has been fixed: we no longer display the image extension. I opened another
bug previously abou tneeding the imag type from nsIImage.