185412 - Mozilla doesn't display OBJECTs, without TYPE attributes and replaced by an image ending with ".jpeg", correctly

Status: VERIFIED DUPLICATE of bug 188586

(Core Graveyard :: Plug-ins, defect)

Description

[Greg K.]

FizzillaMach/2002121307 and Win32/2002102704 don't display OBJECTs, without TYPE
attributes and replaced by an image ending with ".jpeg", correctly.

Specifically, such an OBJECT displays at Mozilla's default OBJECT size and gets
scroll bars when it should display with the image's intrinsic size.

When type="image/jpeg" is added, it works fine, and when the image ends in .jpg,
it also works fine.

Always reproducible by accessing the given testcase URL.

Comment 1

[Christopher Hoess (gone)]

Yeah, I see this too. Maybe the plugins folks know something about this; related
to bug 95549 maybe?

Comment 2

[Jason Summers]

Possibly a duplicate of bug 96579, based on other bugs that have been duplicated
against it. Bug 95548 and bug 140975 are also essentially the same issue. (Not
bug 95549 though -- it does not apply if "type" is not present.)

Comment 3

[rubydoo123]

reassign

Comment 4

[Christopher Hoess (gone)]

er, the reassign didn't work. sending to peterl, who seems to hold all the 
related bugs.

Comment 5

[Peter Lubczynski]

Attachment: patch v.1 (hack)

If you were to use viewer.exe to dump frames you'd see the scrollbars on the
image are there because it is being rendered through as though it was an IFRAME
rather than an IMG tag. That's because in nsObjectFrame::IsSupportedImage there
is a hard-coded check for extensions and "JPEG" isn't on the list. This patch
adds it to the list but it's really not the right way.

The right way is fixing bug 157554 and handling the case where we need to pass
off the opened stream to imglib.

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Why bother with this hack? Why not just fix it right?

Comment 7

[Peter Lubczynski]

The hack is easy, low risk, and will be nuked when fixed the right way. The
"right fix" is quite a bit more involved and has more risk but is planned during
the re-write.

Comment 8

[av (gone)]

Comment on attachment 109422 [details] [diff] [review]
patch v.1 (hack)

r=av

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 109422 [details] [diff] [review]
patch v.1 (hack)

sr=roc+moz

Yeah, I'd love to see all this moved into content.

Comment 10

[Ruslan Ismailov]

Seems, that patch for bug 189079 fix it. I compare Mozilla/5.0 (Windows; U;
Windows NT 5.1; en-US; rv:1.3b) Gecko/20030114 with self-compiled with Bernd's
patch.

Comment 11

[Peter Lubczynski]

actually, this was fixed by bug 188586.

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