Closed
Bug 185412
Opened 22 years ago
Closed 22 years ago
Mozilla doesn't display OBJECTs, without TYPE attributes and replaced by an image ending with ".jpeg", correctly
Categories
(Core Graveyard :: Plug-ins, defect)
Core Graveyard
Plug-ins
Tracking
(Not tracked)
VERIFIED
DUPLICATE
of bug 188586
People
(Reporter: bugmail, Assigned: peterl-bugs)
References
()
Details
(Keywords: html4, Whiteboard: [HTML4-13.3])
Attachments
(1 file)
970 bytes,
patch
|
serhunt
:
review+
roc
:
superreview+
|
Details | Diff | Splinter Review |
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•22 years ago
|
||
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]
Comment 2•22 years ago
|
||
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•22 years ago
|
||
reassign
Comment 4•22 years ago
|
||
er, the reassign didn't work. sending to peterl, who seems to hold all the related bugs.
Assignee: beppe → peterl
Comment 5•22 years ago
|
||
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.
Updated•22 years ago
|
Attachment #109422 -
Flags: superreview?(roc+moz)
Attachment #109422 -
Flags: review?(av)
Why bother with this hack? Why not just fix it right?
Comment 7•22 years ago
|
||
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+
Comment 10•22 years ago
|
||
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•22 years ago
|
||
actually, this was fixed by bug 188586. *** This bug has been marked as a duplicate of 188586 ***
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•