Closed Bug 185412 Opened 18 years ago Closed 18 years ago

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

Categories

(Core :: Plug-ins, defect)

defect
Not set
normal

Tracking

()

VERIFIED DUPLICATE of bug 188586

People

(Reporter: bugmail, Assigned: peterl-bugs)

References

()

Details

(Keywords: html4, Whiteboard: [HTML4-13.3])

Attachments

(1 file)

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.
Yeah, I see this too. Maybe the plugins folks know something about this; related
to bug 95549 maybe?
Assignee: frame → beppe
Component: Layout: HTML Frames → Plug-ins
Keywords: html4
QA Contact: amar → shrir
Whiteboard: [HTML4-13.3]
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.)
reassign
er, the reassign didn't work. sending to peterl, who seems to hold all the 
related bugs.
Assignee: beppe → peterl
Attached patch patch v.1 (hack)Splinter Review
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.
Attachment #109422 - Flags: superreview?(roc+moz)
Attachment #109422 - Flags: review?(av)
Why bother with this hack? Why not just fix it right?
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.
Depends on: 157554
Comment on attachment 109422 [details] [diff] [review]
patch v.1 (hack)

r=av
Attachment #109422 - Flags: review?(av) → review+
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.
Attachment #109422 - Flags: superreview?(roc+moz) → superreview+
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.
actually, this was fixed by bug 188586.

*** This bug has been marked as a duplicate of 188586 ***
Status: NEW → RESOLVED
Closed: 18 years ago
No longer depends on: 157554
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.