678 - text/html and text/plain OBJECTs don't work

Status: VERIFIED FIXED

(Core :: Layout, defect, P3)

Description

[Angus Davis]

This page contains several Object tag tests. I couldn't get any of them to
work in Raptor. I'm using the release build.

Comment 1

[Alex Musil]

Changing platform to ALL since this is most likely an XP problem

Comment 2

[Alex Musil]

Changing platform to ALL since this is most likely an XP problem

Comment 3

[Alex Musil]

*** Bug 1155 has been marked as a duplicate of this bug. ***

Comment 4

[Alex Musil]

*** Bug 1156 has been marked as a duplicate of this bug. ***

Comment 5

[Alex Musil]

*** Bug 1158 has been marked as a duplicate of this bug. ***

Comment 6

[Alex Musil]

Andrei - can you meet with Kipp and/or Troy sometime in the next few days to go
over object tag issues?

Comment 7

[leger]

Setting all current Open/Normal to M4.

Comment 8

[Paul MacQuiddy]

per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

Comment 9

[rubydoo123]

assigning Eli as QA contact

Comment 10

[av (gone)]

This can be considered fixed as to original incorrect behaviour

Comment 11

[rubydoo123]

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.

Comment 12

[Michael Schumann]

I tried the "HTML and plain text documents" tests at the attached site and they
do not work on Windows M8

Comment 13

[leger]

Clearing Fixed resolution due to Reopen.

Comment 14

[leger]

Moving from M4 to M9 since M4 way gone.

Comment 15

[av (gone)]

Michael, did they work in previous spins?

Comment 16

[Michael Schumann]

I tried it in M4 or so and it didn't work then either.

Comment 17

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

See http://www.w3.org/TR/html40/struct/objects.html#h-13.5 for what HTML has to
say on this.

Comment 18

[rubydoo123]

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

[av (gone)]

Lowering priority and moving

Comment 20

[Eli Goldberg]

Hi, Beppe ---

This looks object related; would that be petersen? (it's not me)

thanks!

Comment 21

[Eli Goldberg]

Shrirang is now QA owner for Plug-ins; QA assigning all of my Plug-ins bugs over
to him.

Comment 22

[Hixie (not reading bugmail)]

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

[Hixie (not reading bugmail)]

s/bug 22047/bug 22037/
shoot py8ieh=[e-mail]

Comment 24

[Scott A. Colcord]

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

[Richard Zach]

*** Bug 36312 has been marked as a duplicate of this bug. ***

Comment 26

[sungod]

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

[Antti Näyhä]

I agree that this is important - adding 'nsbeta3' keyword because it's probably
too late for nsbeta2.

Comment 28

[Antti Näyhä]

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"?

Comment 29

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

[Antti Näyhä]

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).

Comment 31

[James Palmer]

Status Whiteboard: [e-mail]
Keywords: makingtest


This is my first bug, so I can't edit the SW or Keywords fields yet, hence the 
above.

James

Comment 32

[James Palmer]

Attachment: Attempts to display embedded HTML and text files, using every combination of DATA, TYPE and (WIDTH and HEIGHT) parameters in the OBJECT tag

Comment 33

[Antti Näyhä]

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 
[e-mail] to Status Whiteboard.

PS. Welcome, Jamie! :-)

Comment 34

[Antti Näyhä]

FYI: In addition to IE, this is now supported by Opera, too (starting from 
v4.0).

Comment 35

[Marc Attinasi]

av, please provide any new information on this bug so we can evaluate it as a 
candidate for beta3- Thanks.

Comment 36

[Braden]

This wasn't working in Navigator 4.x. Removing 4xp keyword.

Comment 37

[Antti Näyhä]

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

[Antti Näyhä]

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."

Comment 39

[steve]

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

[Paul A Smith]

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

[Antti Näyhä]

> 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.

Comment 42

[Peter Lubczynski]

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.

Comment 43

[Peter Lubczynski]

Adding Marc. Is this the oldest bug?

Comment 44

[Joel Turner]

No there are seven open bugs older than this one starting with bug 350.

Comment 45

[Thomas Deniau]

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 !

Comment 46

[Peter Lubczynski]

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>.

Comment 47

[Braden]

(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

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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...)

Comment 49

[Peter Lubczynski]

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.

Comment 50

[Alexey Chernyak]

*** Bug 81557 has been marked as a duplicate of this bug. ***

Comment 51

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

[Stefan Huszics]

"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

[Christopher Hoess (gone)]

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?

Comment 54

[Peter Lubczynski]

..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.

Comment 55

[Peter Lubczynski]

Attachment: first crack at a patch to get this working v.1

Comment 56

[Peter Lubczynski]

Attachment: slightly better patch, passing testcase url, v.2

Comment 57

[Bradley Baetz (:bbaetz)]

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

[Braden]

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

[av (gone)]

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">

Comment 60

[Peter Lubczynski]

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

[Bradley Baetz (:bbaetz)]

"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

[timeless]

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.

Comment 63

[Peter Lubczynski]

Attachment: cleaned up patch now using browser services, v.3

Comment 64

[av (gone)]

In this patch I don't see you deleted old image specific stuff. Shouldn't we do 
that?

Comment 65

[Braden]

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

[av (gone)]

My last comment is not relevant. I like the patch so far. r=av

Comment 67

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

[Trevor Andreas]

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

[Christopher Hoess (gone)]

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

[Greg K.]

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

[Bradley Baetz (:bbaetz)]

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

[Braden]

bbaetz: Not directly; but the OBJECT's background should show through if the
embedded document's background is transparent.

Comment 73

[Greg K.]

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

[Greg K.]

(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

[Bradley Baetz (:bbaetz)]

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

[Greg K.]

Whoops, wrong bug number for that IFRAME transparency issue. It's really bug 50623.

Comment 77

[Peter Lubczynski]

*** Bug 95063 has been marked as a duplicate of this bug. ***

Comment 78

[Peter Lubczynski]

..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

[Braden]

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

[Marc Attinasi]

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?

Comment 81

[Peter Lubczynski]

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

[av (gone)]

I think we do this. Just because <embed> tag goes through the <object> code 
path.

Comment 83

[Greg K.]

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

[Braden]

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

[Marc Attinasi]

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

[av (gone)]

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

[av (gone)]

Attachment: The document describing a possible plan to imolement the dynamic sizing

Comment 88

[Antti Näyhä]

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

[rbs]

+    char * contentType;  <------------------------------- leaked in the patch
+    rv = mimeService->GetTypeFromURI(uri, &contentType);
+    if (NS_FAILED(rv)) return;
+

Comment 90

[Peter Lubczynski]

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

Comment 91

[Stefan Huszics]

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

[bsharma]

Marking verified as per above developet comments.

Comment 93

[Koike Kazuhiko]

I found two remaining problem.

Bug 96579: <object> with absolute URL and without MIME type doesn't work
Bug 96580: Changing URL in DATA attribute of OBJECT doesn't take effect

Comment 94

[Greg K.]

I also have found a problem: see bug 96976 about OBJECT (and IFRAME) alternate
content not being displayed when appropriate.

Comment 95

[Hixie (not reading bugmail)]

Is there a bug about the fact that % height and width attributes don't work on
the object element?

Comment 96

[Stefan Huszics]

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

[Jens-Erik Weber]

Attachment: object text/html style="position: fixed" vanishes after clicking it or scrollbar!

Comment 98

[Jens-Erik Weber]

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

[Greg K.]

Jens-Erik, that problem should be reported as a new bug, as this bug is
rightfully fixed and thus closed.

Comment 100

[Jens-Erik Weber]

O.k., I've submitted this above mentioned issue as bug #98166.

Comment 101

[Heikki Toivonen (remove -bugzilla when emailing directly)]

SPAM. HTML Element component is deprecated, changing to Layout component. See
bug 88132 for details.

Comment 102

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Come on Bugzilla, you can do it...

Comment 103

[Christopher Aillon (sabbatical, not receiving bugmail)]

*** Bug 115309 has been marked as a duplicate of this bug. ***