Closed
Bug 678
Opened 27 years ago
Closed 24 years ago
text/html and text/plain OBJECTs don't work
Categories
(Core :: Layout, defect, P3)
Core
Layout
Tracking
()
VERIFIED
FIXED
mozilla0.9.4
People
(Reporter: angus, Assigned: peterlubczynski-bugs)
References
()
Details
(Keywords: html4, relnote, testcase, Whiteboard: jamie@adl-london.com relnote-devel (py8ieh: % height and width on object))
Attachments
(6 files)
(deleted),
text/html
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
text/html
|
Details | |
(deleted),
text/plain
|
Details |
This page contains several Object tag tests. I couldn't get any of them to
work in Raptor. I'm using the release build.
Assignee: michaelp → amusil
Status: ASSIGNED → NEW
Component: Unknown → Plug-ins
Comment 1•26 years ago
|
||
Changing platform to ALL since this is most likely an XP problem
Comment 2•26 years ago
|
||
Changing platform to ALL since this is most likely an XP problem
Updated•26 years ago
|
Assignee: amusil → av
Status: ASSIGNED → NEW
Comment 6•26 years ago
|
||
Andrei - can you meet with Kipp and/or Troy sometime in the next few days to go
over object tag issues?
Comment 8•26 years ago
|
||
per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
Updated•26 years ago
|
QA Contact: 3849 → 1698
Comment 9•26 years ago
|
||
assigning Eli as QA contact
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Comment 10•26 years ago
|
||
This can be considered fixed as to original incorrect behaviour
Updated•26 years ago
|
QA Contact: 1698 → 3849
Updated•26 years ago
|
Status: RESOLVED → VERIFIED
Comment 11•26 years ago
|
||
oh happy day! the object element is working, going through Antti's test suite
and have found other issues, but this particular bug is fixed.
Updated•26 years ago
|
Status: VERIFIED → REOPENED
Comment 12•26 years ago
|
||
I tried the "HTML and plain text documents" tests at the attached site and they
do not work on Windows M8
Comment 13•26 years ago
|
||
Clearing Fixed resolution due to Reopen.
Comment 14•26 years ago
|
||
Moving from M4 to M9 since M4 way gone.
Comment 15•26 years ago
|
||
Michael, did they work in previous spins?
Comment 16•26 years ago
|
||
I tried it in M4 or so and it didn't work then either.
Summary: Object tag does not work → HTML objects are not displayed with object tag
Comment 17•26 years ago
|
||
See http://www.w3.org/TR/html40/struct/objects.html#h-13.5 for what HTML has to
say on this.
Comment 18•26 years ago
|
||
I went through a few of the tests -- specifically some of the image tests and
they render correctly. However, the HTML and plain text tests do not render the
file specificed in the data attribute. I checked to ensure that the file
specified was present in the current directory, and they are both there. I used
the 1999090108 build on win98 -- I do not have access to other platforms at this
time.
Comment 19•25 years ago
|
||
Lowering priority and moving
Updated•25 years ago
|
QA Contact: beppe → elig
Updated•25 years ago
|
QA Contact: elig → beppe
Comment 20•25 years ago
|
||
Hi, Beppe ---
This looks object related; would that be petersen? (it's not me)
thanks!
Updated•25 years ago
|
QA Contact: beppe → elig
Comment 21•25 years ago
|
||
Shrirang is now QA owner for Plug-ins; QA assigning all of my Plug-ins bugs over
to him.
Comment 22•25 years ago
|
||
See also these test cases:
http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/object-unknown.html
http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/object-broken.html
http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/object-noattr.html
They demonstrate bug 797, bug 15019 and bug 22047 respectively.
Shrir: I'm the QA contact for HTML 'alt text' bugs, if you think that the
object elements' alternate content classifies as 'alt text' then feel free to
put me in as QA contact for this bug.
Comment 23•25 years ago
|
||
Updated•25 years ago
|
QA Contact: shrir → py8ieh=bugzilla
Comment 24•25 years ago
|
||
I'd like to suggest a priority boost for this bug, since it's required for
compliance with Sec 13.5 of the HTML spec.
Comment 25•25 years ago
|
||
*** Bug 36312 has been marked as a duplicate of this bug. ***
Comment 26•25 years ago
|
||
PLEASE raise the priority of this bug! Client-side HTML inclusions, using the <
OBJECT> tag, "before:" or "after:" psuedoclasses of CSS2, or the still-in-
development XLink specification are the singular features that will drive the
post-HTML-3.2 web forward fastest. The demand is evident and unavoidable:
anywhere you see HTML documents being embedded within each other on a server
using a script (for instance, any portal page, "slashboxes" down the side of
http://slashdot.org/, the XMLhack summaries on http://www.xml.com/, etc.) could
be done more elegantly and with less server overhead and more securely (thanks
to being able to eliminate added complexity of server-side cgi's or dynamic
scripts) using client-side includes like this one. This is our chance, mozilla:
if we can show That Other Browser Maker (TM) the benefits of an object-oriented,
interconnected web as it was originally intended to be, we can improve the speed
and utility of the web exponentially. Let's make it happen, please!
Oh, by the way, it's also been part of the HTML specification since 1997. We
should allow our collective sense of pride, as browser implementers, to be
wounded that we've allowed the web to exist THIS LONG with such blatant
ignorance of the standards. Shame on us.
Comment 27•25 years ago
|
||
I agree that this is important - adding 'nsbeta3' keyword because it's probably
too late for nsbeta2.
Keywords: nsbeta3
Comment 28•25 years ago
|
||
Hmm. When I think of it, this bug seems to have been opened for general lack of
OBJECT element support in HTML. The summary is a bit misleading - it means
"OBJECT elements in HTML", not "text/html OBJECT elements in HTML".
This is actually fixed now, since the OBJECT element itself and the most
important attributes are working correctly.
Does everybody agree that I should close this bug and open a new one called
"text/plain and text/html OBJECTs don't work"?
OS: Windows NT → All
Comment 29•25 years ago
|
||
Is there a need to close this bug and open a new one? I don't see one. (People
have connections to this bug.) But retitling this one would be fine.
Comment 30•25 years ago
|
||
Right, so I'm retitling this one - we can always open a new bug if the OBJECT
element itself stops working. Also changed the URL to some more specific test
cases.
This probably isn't about plug-ins any more since no plug-in is needed to
display HTML or plain text. Changing Component to HTML Element, although it
could be HTMLFrames just as well?
Also adding 'html4' and '4xp' keywords (the latter because IE4/5 has some
support for this feature).
Component: Plug-ins → HTML Element
Summary: HTML objects are not displayed with object tag → text/html and text/plain OBJECTs don't work
Comment 31•25 years ago
|
||
Status Whiteboard: jamie@adl-london.com
Keywords: makingtest
This is my first bug, so I can't edit the SW or Keywords fields yet, hence the
above.
James
Status: REOPENED → ASSIGNED
Comment 32•25 years ago
|
||
Comment 33•25 years ago
|
||
Er, we already had a valid test case for this one - see the URL field. I'd
also like to point out that the HTML/plaintext OBJECT isn't necessarily 300*200
pixels big if width & height aren't specified, which is what James' test case
implies.
I've already done the maximum number of Bugathon bugs anyway, so I guess the
credit for this goes to James. Adding 'testcase' keyword and
jamie@adl-london.com to Status Whiteboard.
PS. Welcome, Jamie! :-)
Keywords: testcase
Whiteboard: jamie@adl-london.com
Comment 34•25 years ago
|
||
FYI: In addition to IE, this is now supported by Opera, too (starting from
v4.0).
Comment 35•25 years ago
|
||
av, please provide any new information on this bug so we can evaluate it as a
candidate for beta3- Thanks.
Updated•25 years ago
|
Whiteboard: jamie@adl-london.com → jamie@adl-london.com [nsbeta3-]
Target Milestone: M17 → Future
Comment 36•24 years ago
|
||
This wasn't working in Navigator 4.x. Removing 4xp keyword.
Keywords: 4xp → correctness
Comment 37•24 years ago
|
||
Braden: yes, that's true - I'm still a bit confused about the exact meaning
of '4xp'.
(I might as well use this opportunity to draw attention to bug 53954.)
Comment 38•24 years ago
|
||
Suggested release note:
"HTML and plain text documents embedded with the OBJECT element aren't
supported in this release. Workaround: use the IFRAME element instead."
Keywords: relnote
Whiteboard: jamie@adl-london.com [nsbeta3-] → jamie@adl-london.com [nsbeta3-] relnote-devel
Comment 39•24 years ago
|
||
Would like to add that XML files are not
working with the object tag to load files
into a HTML documentor can you point
to an address where it does?
But it does work to load a SVG file
which is also XML(?).
Comment 40•24 years ago
|
||
As suggested above, I'm using IFRAME as workaround for the broken OBJECT element
to include an external text/html source in a table cell. Platform:
Sun-Solaris5.7, Mozilla M18
However, I want the embedded html to fill the available space in the cell, or
even drive it larger as necessary (just as if the cell had been filled directly
inline). However IFRAMEs don't auto-resize. I can set the IFRAME width=100%
which makes it fill the cell horizontally, but for height it seems to require an
integer, which invariably results in clipping or wasted space. Any suggested
solutions to this problem?
Also, what is the new target milestone for the fix to the OBJECT problem? The
"View Bug Activity" list indicates the latest target milestone to be M16. I'm
using M18 and still have the problem.
Comment 41•24 years ago
|
||
> I can set the IFRAME width=100% which makes it fill the cell horizontally,
> but for height it seems to require an integer, which invariably results in
> clipping or wasted space.
If this is true, please file another bug. Percentages should be allowed for
both width and height in both IFRAME and OBJECT.
Keywords: mozilla1.0
Assignee | ||
Comment 42•24 years ago
|
||
Buster,
Would a possible fix for this be to construct a new document inside just like we
do with IFRAMES in the FrameConstructor instead of an nsObjectFrame if the
mime-type is text/html or text/plain?
That's probably just a hack and I don't know how to later deal with modifying
the OBJECT tag through the DOM in this case.
Assignee | ||
Comment 43•24 years ago
|
||
Adding Marc. Is this the oldest bug?
Whiteboard: jamie@adl-london.com [nsbeta3-] relnote-devel → jamie@adl-london.com relnote-devel
Comment 44•24 years ago
|
||
No there are seven open bugs older than this one starting with bug 350.
Comment 45•24 years ago
|
||
The IFRAME element is deprecated in XHTML 1.0 strict. So the only way to embed
an html document is <object> ... Correct this bug FAST !
Assignee | ||
Comment 46•24 years ago
|
||
Stealing away.....
I just went to take a look at nsFrameFrame.cpp, the frame class for IFRAMEs and
it doesn't look like simply creating this type of frame instead of an object one
and leaving the content the same will work as is done with the object tag and
images. Looks like there is too much reliance on the content. So, I see two ways
of fixing this:
1) [Easy Way] Is to simply change the content node if OBJECT type=text/html to
that of an IFRAME and let nsFrameFrame.cpp do all the work. This seems like a
bit of a hack and I'm not quite sure how the DOM would like us replacing the
author's content with that of deprecated content? I'm not even quite sure the
author and spec would even be effected or notice. Any core layout junkies know?
2) It doesn't look like there is a whole lot of code needed to create a webshell
and docshell subdocuments in nsFrameFrame.cpp. Hooking up the views and view
managers looks most complicated. A few things already stand out in my mind as
needing special attention such as printing and events. Since nsObjectFrame.cpp
is already huge, at least one more class would need to be created. Seems like a
lot of work.
3) [Just thought of this one] Does the spec say anything is wrong with actually
creating a plugin to handle types of text/html? Instead of creating another
frame class, could one create an XPCOM plugin to handle XHTML mime types? How
would this interfear with the DOM? I guess XPConnect could be used for
scripting.
Question, what ever happened to using DIVs to do this? Do they still accept the
SRC= attribute? I bet that's deprecated in XHTML 1.0 strict too. So the only way
to embed an html document is with <object>.
Assignee: av → peterlubczynski
Status: ASSIGNED → NEW
Comment 47•24 years ago
|
||
(3) strikes me as exactly the way this ought to work. (Indeed, that's how I'd
assumed it would be implemented all along. Shows what I know....)
I don't know what you're referring to with DIVs; they haven't had a SRC
attribute in any version of standard HTML (it's not even there to be deprecated).
Comment 48•24 years ago
|
||
What about the variant of (1) that would use anonymous content as a child of
the OBJECT rather than replacing the object element in the DOM? (I'd rather
see the anonymous content creation with XBL, although it would probably be
easier to just do another implementation of nsIAnonymousContentCreator...)
Assignee | ||
Comment 49•24 years ago
|
||
Anonymous content creation with XBL sounds like it may be the way to go but I'm
not too familiar with XBL or the nsIAnonymousContentCreator. Are there some good
examples in code you can point me to? cc:ing Hyatt
Looking again at object frame, for images at least, it creates an image frame
that's a child of the empty object. I guess I could make an nsFrameFrame the
child. Either way a new webshell will need to be created. cc:ing Adam Lock for
his input.
Doing this in layout (#1) would probably be a more tightly coupled
implementation whereas using plugins would be more "plug-able".
Another variation of #3 is to create a 4.x plugin wrapper and use that in
Mozilla and other bowsers. It probably would be quite simple as we already do
that with ActiveX for with the MozControl. Just think, Nav 4.x and IE could use
Gecko as it's rendering engine on both Mac and Windows.
Status: NEW → ASSIGNED
Comment 50•24 years ago
|
||
*** Bug 81557 has been marked as a duplicate of this bug. ***
Comment 51•24 years ago
|
||
I was just wondering (see bug 77539) whether an OBJECT embedding a text/html
document should look like an IFRAME. Perhaps it shouldn't, except that it
should have 'overflow: auto' by default so that if height and width are given
then it will get scrollbars if the contents are larger? Without height and
width, should it just embed one document in another? Also see
http://www.w3.org/TR/html4/struct/objects.html#embedded-documents
Comment 52•24 years ago
|
||
"Just think, Nav 4.x and IE could use
Gecko as it's rendering engine on both Mac and Windows."
Oh boy, I'm getting wet dreams already.
Instead of making NEW pages compatible with OLD browsers one could make OLD
browsers compatible with NEW pages!!
Beeing able to make a feature rich XHTML/CSS2 webpage and not having to worry
about NS4.x and IE **** all over it sounds too good to be true.
Is this doable ?
It could even be an excellent way to "advertize"/introduce NS6.x to Windows IE
users if gecko could seamlessly integrate with IE and "take over" the rendering
after showing a splash screen or something.
Comment 53•24 years ago
|
||
We should be able to support:
text/plain (plaintext)
text/xml, application/xml (xml)
text/html (html)
application/vnd.mozilla.xul+xml (XUL)
application/xhtml+xml (XHTML)
text/rtf (rtf) [our support is a little crufty right now, but why not?]
inside objects. Can anyone think of others?
Assignee | ||
Comment 54•24 years ago
|
||
..attaching patch that makes this WORK!!! We already handled images nativly in
the OBJECT tag. This patch extends on the that framework by creating a new
nsHTMLFrameOuterFrame. It's not a perfect solution, but at least this does
something to get our XHTML correct. This bug has 31 votes, eek! I'm seeking reviews.
Since we are entering the world of IFRAMEs, cc:ing mstoltz for security concerns.
Keywords: patch
Target Milestone: Future → mozilla0.9.4
Assignee | ||
Comment 55•24 years ago
|
||
Assignee | ||
Comment 56•24 years ago
|
||
Comment 57•24 years ago
|
||
Why do we need IsSupportedDocument? Isn't the correct thing just to use the
category manager (see nsContentDLF.cpp), rather than adding yet another place
where new document types have to be added?
If theres no type argument, then we should try the mime service for extention
matching. Doing extention matching is evil, but if we're going to do it, it
should be done right :)
Can we use this for <embed>, as well? (if a plugin isn't installed and we can
deal with the mimetype internally)
Comment 58•24 years ago
|
||
I haven't looked at the patch, but the type argument should only be used to
discern if it's not appropriate to download the data (that is, if it's a
completely unsupported data type). If the type argument is absent, the download
should be initiated. If the server at that point does not tell the client the
content type of the file, then and only then is it appropriate to use filename
extension or content-based guessing about the content type.
Comment 59•24 years ago
|
||
The patch does essentially mimic what we already do for images. Great effort,
Peter! My concern is: when it was image only, we used to merely check for
existance of a child frame to determine that we deal with an image. Now we
should probably introduce a flag, some sort of enumeration type if we need to
distinguish between images and different types of documents. Just a thought, I
don't know yet if we really need it.
Bradley Baetz wrote:
>Can we use this for <embed>, as well? (if a plugin isn't installed and we can
>deal with the mimetype internally)
<embed> results in the same code path, so it should just work I think. Hmm...
interesting point. Never tried <embed src="test.jpg">
Assignee | ||
Comment 60•24 years ago
|
||
I glanced through nsObjectFrame.cpp and it appears the only important place we
check for a child is in Reflow() where we are unconditonally calling
HandleImage() to do a special reflow if there are any children. Right now, I see
nothing in the code for HandleImage() that would prevent it for working with
documents as well. Looks pretty generic. Perhaps I'll just change the name or am
I missing something? Is there another place I'm missing where we handle
OBJECT-tag images special?
nsContentDLF.cpp seems to be for content-viewer creation and doesn't seem to be
what I need.
For the IsSupported[Image|Document] call, what I really need is a service that I
can pass a MIME-type and it returns a value indicating this is something we can
render internally.
You are right about comparing the file extensions. I found
nsIMIMEService::GetTypeFromURI(nsIURI) may work better in both documents and
images as (should) return a mime-type for a given URL based on extension
parsing. I would also like to use nsIMIMEInfo::GetPreferredAction(action) but
either I didn't use it correctly or it was incorrectly returning saveToDisk
instead of handleInternally. Is there another way to do this?
Images using the OBJECT tag do not check the content-type in the header at all
and neither will docuemnts for now. I looked into changing this, as per spec,
and it ain't easy due to the current way Reflow() works to instatiate a plugin.
This last check for mime-type happens deep inside plugin streaming code and it
only calls back to the plugin host, which after all, assumes it's going to be a
plugin. For that to work for images and documents, we'd have to have some
callback to the ObjectFrame, possibly through an nsPluginInstanceOwner, and also
destroy any plugin data structures created at that point. Becase that effects
both this bug and OBJECT-tag images, perhaps we should open another bug on this
specific issue.
Comment 61•24 years ago
|
||
"For the IsSupported[Image|Document] call, what I really need is a service that
I can pass a MIME-type and it returns a value indicating this is something we
can render internally."
http://lxr.mozilla.org/seamonkey/source/docshell/base/nsDSURIContentListener.cpp#162
should do what you want. This is a public method on nsIURIContentListener, and
parentURIContentListener is an attribute on the docshell. CanHandleContent
should be OK if you check plugins first - I don't know if IsPreferred will
respond to things which have external helper apps registered.
The value from the category manager service is just the contract id for the
viewer, and I don't think anything uses that directly (see
http://lxr.mozilla.org/seamonkey/source/docshell/base/nsDocShell.cpp#3884).
nsIMIMEInfo::GetPreferredAction was probably returning "saveToDisk" because I
think we don't use that for checking for handling stuff internally - we use the
categorymanager instead. I'm not 100% sure about that though.
Comment 62•24 years ago
|
||
fwiw, data:text/html,<embed src=about:logo> crashed my nc4 for various reasons,
#1 was the real jukebox plugin, later i crashed w/
data:text/html,<html><embed src=about:logo></embed></html> in general netscape4
land.
Assignee | ||
Comment 63•24 years ago
|
||
Comment 64•24 years ago
|
||
In this patch I don't see you deleted old image specific stuff. Shouldn't we do
that?
Comment 65•24 years ago
|
||
Peter: Definitely agreed re. opening another bug. Since you seem to have a good
handle on the problem with respect to the current code, could you do this (and
CC me)? Note that this is an HTTP conformance issue.
The TYPE attribute on OBJECT is *just a hint* the the browser can use to
determine whether or not it should try to download the data. It is not a
required attribute. And if the media type sent by the server happens to differ
from that in the TYPE attribute, the client *must* honor the type sent by the
server. It sounds like Mozilla may need substantial fixing in this regard.
Comment 66•24 years ago
|
||
My last comment is not relevant. I like the patch so far. r=av
Comment 67•24 years ago
|
||
Do we really want to make OBJECT elements linking to document formats work just
like IFRAMEs, or do we want to come up with a better solution (see my
2001-05-22 comments)? Whatever we do here is likely to be adopted by other
browsers and become the standard, and if we make this work just like IFRAME
then we'll just have another redundant feature of HTML rather than something
new and useful.
Comment 68•24 years ago
|
||
I would have to agree -- I always envisioned text/html objects to embed much
like using ssi, or even when you pulled in content using the src attribute of
the layer element in 4.x...
Comment 69•24 years ago
|
||
FWIW, I don't see this as working as similar to ssi include. An included html
document will be just that-an html document, not a document fragment, and can't
readily be shoved into the content tree of the current document. Furthermore,
IE 5.5 already does this as an IFRAME-like thing; I'm not sure quite what we
should do differently in terms of display, although obviously we should make
sure that context menus, URI resolution, etc., work correctly.
Comment 70•24 years ago
|
||
External XML entities provide functionality akin to SSI's.
Of course, I don't seemt to be able to get them to work in 0.9.3...I thought
they worked at one point.
Comment 71•24 years ago
|
||
Should html/xml in <embed> be subject to the stylesheets in the parent document?
SVG (which is the only spec I know of that defaines what happens when a documend
it embedded in another) says no, and I don't think it makes sense to do so.
Comment 72•24 years ago
|
||
bbaetz: Not directly; but the OBJECT's background should show through if the
embedded document's background is transparent.
Comment 73•24 years ago
|
||
bbaetz: no, styles on the parent document should not apply to embedded
documents. The parent/embedded document boundary should be considered as a brick
wall as far as style information is concerned, with the exception of the matter
Braden mentions, which is if the embedded document's body is styled
"background-color: transparent" then the parent's background should show through
behind the embedded document.
This is not how Mozilla's only embedding mechanism, IFRAME, presently works. See
bug 50263.
Comment 74•24 years ago
|
||
(Of course, I should point out that the notion of background transparency isn't
really an "exception" to my brick-wall analogy; in truth, background
transparency simply means that the embedded document will draw no background
behind the embedded document's content. Thus the brick wall stays intact.)
Comment 75•24 years ago
|
||
Exactly, but ssi's don't work that way (they're, well, included). Which is whjy
I asked. I think that borderles iframes are probably the way to go. If its not
an applet, we could try to load it normally as an iframe, and let the standard
content-type handlers deal with it.
Comment 76•24 years ago
|
||
Whoops, wrong bug number for that IFRAME transparency issue. It's really bug 50623.
Assignee | ||
Comment 77•24 years ago
|
||
*** Bug 95063 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 78•24 years ago
|
||
..addressing some of dbaron's issues:
1) I think 'overflow: auto' is already set as I get scrollbars automatically
2) Could not find anything which this implementation would violate at:
http://www.w3.org/TR/html4/struct/objects.html#embedded-documents
3) With no height and width specified, with an OBJECT tag, we should not display
anything, not even alternate content. This is what IE 5.5 does. We do the wrong
thing here anyway though. I'll file a new bug.
4) I also found some other bugs in terms of the spec in our implementation of
OBJECT tag in general. I will file new bugs.
5) It at least gets _something_ working to bring us to spec and it's similar to
the way we do images with the OBJECT tag.
Comment 79•24 years ago
|
||
I disagree on point 3. IE is wrong about this. HEIGHT and WIDTH are optional
attributes; they are presentational hints. They should not be required to
display something. Note 13.7.1 in the HTML 4.01 spec: "When specified, the width
and height attributes tell user agents to override the natural image or object
size in favor of these values."
The "natural size" of an image or object is rarely zero.
<img src="image.png" alt="Alt text">
should be presented the same way as
<object data="image.png">Alt text</object>
Comment 80•24 years ago
|
||
What is the natural size of a flash animation, or a quick-time movie, or a real
video stream? Can we determine those like we can the intrinsic size of an image?
Assignee | ||
Comment 81•24 years ago
|
||
But what is the "natural size" of a plugin or document? There is nothing in the
plugin API to ask a plugin what its desired size is. The spec is unclear about a
default size when one can not be determined. We do default to constants for the
EMBED tag. Using an IFRAME tag we seem to default to the same size as IE. I
think we should do similar for OBJECT.
Comment 82•24 years ago
|
||
I think we do this. Just because <embed> tag goes through the <object> code
path.
Comment 83•24 years ago
|
||
Certainly OBJECT's, like any other HTML element, should default to CSS2 width
and height values of auto.
There was also some discussion of this problem in bug 90753 in regards to
Acrobat PDF's. It seems we may need to revise the plug-in specification to
facilitate communication of the intrinsic dimensions of the embedded data back
to layout.
As we can see in
[http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsObjectFrame.cpp#627],
arbitrary dimensions of 240px by 200px are assigned when an object's intrinsic
dimensions cannot be determined, such as when a plug-in is involved. Try the
testcase associated with that bug; you'll see the PDF assumes those dimensions.
Try assigning the style, "width: 500px" to the OBJECT, and you'd expect it to
then become 500px by 200px, but you'll be surprised to see both height and width
become 500px.
Comment 84•24 years ago
|
||
That would be a notable deficiency of the plug-in API. Picking an arbitrary size
(other than zero) is an acceptable workaround, but there really needs to be a
way to ask the plugin instance what size it "wants".
For vector formats, I think it's probably just as well that the plugin instance
can't suggest a size to the host document. But for raster formats--notably
movies--this is a real problem.
Comment 85•24 years ago
|
||
fix NULL --> nsnull, rv == NS_OK --> NS_SUCCEEDED, then sr=attinasi
This solution is fine, but it will not support dynamic changes to the data=
attribute (i.e. the IFrame will not be updated to the new URL) - but, we don't
really support that now anyway except when it is for an image ;) Open anohter
bug on that if you like...
Comment 86•24 years ago
|
||
Some time ago we even started a project to implement dynamic plugin sizing. See
http://warp.mcom.com/core/plugins/projects/ and even have some leftovers in the
current code. The idea was not to ask a plugin for the desired size but rather
to respond to the plugin's request for the size it wants. The plan was to use
NPN_SetValue call and we even have a defined variable specifically for this
purporse.
Comment 87•24 years ago
|
||
Comment 88•24 years ago
|
||
I filed bug 8740 on the dynamic sizing issue two years ago. See my comments
there (1999-06-23 and 2000-06-27) about why it's so important.
The bug was finally resolved by setting the default size larger (240*200 px).
This is what Andrei commented on that bug 2000-07-27:
> plugin manufacturers can now change the plugin window size dynamically via
> nsIPluginInstancePeer interface, so ideally, as I see it, the plugin itself
> can determine the image size at the moment the stream starts to come to the
> plugin and adjust its size accordingly.
...which made me think we already support dynamic sizing, it's just the
then-current plugins that don't.
But this discussion should really continue in a new bug. This bug is
specifically about supporting text/html and text/plain OBJECTs (and possibly
other native formats).
Comment 89•24 years ago
|
||
+ char * contentType; <------------------------------- leaked in the patch
+ rv = mimeService->GetTypeFromURI(uri, &contentType);
+ if (NS_FAILED(rv)) return;
+
Assignee | ||
Comment 90•24 years ago
|
||
Marc's suggestions checked in. Leak-fix also checked in. Marking bug fixed.
New bugs opened:
bug 95548 OBJECT tag's type can't be changed later (like through the DOM)
bug 95549 OBJECT tag: Content-type header should take precedence
Status: ASSIGNED → RESOLVED
Closed: 26 years ago → 24 years ago
Resolution: --- → FIXED
Comment 91•24 years ago
|
||
A question, should these new bugs be listed on the Bug 7954
([META] outstanding issues for full HTML 4.01 support),
or are these "small enough" not to be relevant on that list ?
(actually the first would belong to the DOM I guess, but what about the second)
Comment 92•23 years ago
|
||
Marking verified as per above developet comments.
Status: RESOLVED → VERIFIED
Comment 93•23 years ago
|
||
Comment 94•23 years ago
|
||
I also have found a problem: see bug 96976 about OBJECT (and IFRAME) alternate
content not being displayed when appropriate.
Comment 95•23 years ago
|
||
Is there a bug about the fact that % height and width attributes don't work on
the object element?
Whiteboard: jamie@adl-london.com relnote-devel → jamie@adl-london.com relnote-devel (py8ieh: % height and width on object)
Comment 96•23 years ago
|
||
I don't know, but I bumped into this with iframes just the other day so it's not
just objects.
Then again, neighter IE 6.0beta or Opera 5.12 got iframes right either, so I
just dropped the whole idea and made a normal frame. =(
Iframes however is on the way out of the specs and cosidering no other browser
gets it right also it's not a major issue. Fixing it for objects though seems
highly relevant.
/Stefan Huszics
Comment 97•23 years ago
|
||
Comment 98•23 years ago
|
||
Object text/html vanishes after clicking it or scrollbar
An object of type text/html with style="position: fixed" is rendered correctly
(finally, congratulations!!! :-), but as soon as you click the scrollbar of the
containing document or into the object (link, scrollbar or anywhere else), it
vanishes; the border (coloured for testing purposes) remains. See
<http://pc00ep5.physik.uni-augsburg.de/test.html>. It would be so useful for
navigation to have a text/html object with position: fixed, because you only
have to maintain one navigation document for the whole site and with position:
fixed it can replace frames, that are not in the strict DTDs, so please fix it!
Comment 99•23 years ago
|
||
Jens-Erik, that problem should be reported as a new bug, as this bug is
rightfully fixed and thus closed.
Comment 100•23 years ago
|
||
O.k., I've submitted this above mentioned issue as bug #98166.
SPAM. HTML Element component is deprecated, changing to Layout component. See
bug 88132 for details.
Come on Bugzilla, you can do it...
Component: HTML Element → Layout
Updated•23 years ago
|
Attachment #11035 -
Attachment mime type: application/octet-stream → text/html
*** Bug 115309 has been marked as a duplicate of this bug. ***
You need to log in
before you can comment on or make changes to this bug.
Description
•