1999042908 build, Windows NT. If you load the above URL (or any URL that points to an image), the window title remains the same as what it was before (say, the URL of the previously viewed page). Expected result: it changes to read "<type> image <size> pixels" (where type and size are dynamically generated).

This is not a UI design bug. reassign to Don or his team.

Assigned to davidm for M6.

accept and move off until m8

QA assigning several orphaned UI/UE bugs. cpratt, I'm giving you the ones you wrote :-), and I'll take the rest.

I think this is a parser/DTD thingy. When we load a jpeg we should be generating a title tag with the desired info. reassigning to the layout to get their opinion on who should be generating this info.

nsImageDocument::CreateSyntheticDocument() needs to obtain the image size and set the document title accordingly. This may be an easy kill for you.

Accepting bug...

I just checked in a partial fix for this bug. The implementation details of this fix are as follows. We now set the title of the image to "Image: width x height pixels", where width and height are the dimensions of the image being displayed. This title is set from nsImageDocument::EndLayout(), a newly added method, that gets called from nsImageListener::StopRequest() which, in turn, is called by netlib once the image stops loading. The size of the image is now displayed on the title bar. We need to figure out whether we need to display the type of the image. .gif files display "GIF Image" and .jpg files display "JPEG Image" in the title bar in Nav 4.x. I think we'll need to look at the file extension to human readable string mapping available on each platform to do this right. Will the XP registry provide a set of keys to access this platform specific mapping? CCing rickg, rpotts, vidur, radha, bill law, and dp. Somebody should know the answer! :-) Setting target milestone to M11 for fixing this bug completely.

First the mappings should be .gif -> image/gif -> "GIF IMAGE" Always use mimetypes and only provide extensions to mimetype mapping to keep this sane. So how would we get a human redable string for a mimetype. I think this should be part of the despatch mechanism of what to do when we get a mimetype (show by navigator, helper app, plugins). It might be stored in the registry untimately.

Pam, I have access to the image request via nsIImageRequest within nsImageDocument. Can I use that interface to get type information about the image that is currently loading? I got your reply to my email earlier (pasted below) and thought I'd ask my followup question on the bug report itself. --- Image lib has IL_Type() which calls il_type() to verify/test the image header for format type. We do have to start with a file extension guess in netlib to call the imglib. ---

Not a beta blocker. Pushing to M14...

Bulk moving all M14 non-beta stopper bugs to M17...

*** This bug has been marked as a duplicate of 24478 ***

Verifying as duplicate of a bug filed 18,771 bug reports later.