Closed Bug 161891 Opened 23 years ago Closed 13 years ago

object tag doesn't work correctly with params

Categories

(Core Graveyard :: Plug-ins, defect, P2)

Product:
Core Graveyard
Component:
Plug-ins
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: arun, Assigned: arun)

References

Details

(Keywords: html4, testcase, topembed-, Whiteboard: [META] [PL2:NA] [HTML4-13.3.2])

Attachments

(4 files)

test case
746 bytes, text/html
Details
Test Case invoking Flash with all the usual param tags
774 bytes, text/html
Details
HTML with an object tag along with a param with "movie" attribute and value pointing to the SWF file.
698 bytes, text/html
Details
SWF file that goes along with the HTML test case.
56.35 KB, application/octet-stream
Details
Could the fix to bug 152334 have stopped object tags from working with some param attributes? Try : <object id="myobj" .... codebase="someURL.xpi" type="application/x-shockwave-flash" height=.. with=...> <param name="src" value="someSWF-File.swf"> .... ... </object> It seems that now, we not only prefer *data* attribute to do this, but we expect it, and thus no longer work with param with "src". This is in fact both a standards compliant way of doing this, and an "old favorite" way to invoke certain plugins, especially Flash.
I believe Peter did some work in this area -- maybe he was a bit too aggressive. ANdrei, can you take a look at this and see what's up?
Assignee: beppe → av
Keywords: nsbeta1+
Priority: -- → P2
Whiteboard: [PL2:NA]
Target Milestone: --- → mozilla1.2alpha
Keywords: topembed
Whiteboard: [PL2:NA] → [adt1] [PL2:NA] [ETA Needed]
this testcase wor sfor me: http://jazz,mcom.com/users/shrir/publish/objdata.html <HTML> <BODY> <OBJECT TYPE="application/x-mplayer2" height="500" width="500"> <PARAM NAME="SRC" VALUE="http://www.geocities.com/MotorCity/Pit/3571/martial/mikemookjong2.avi"> </OBJECT> </BODY> </HTML>
Attached file test case —
WFM. I think it would be more appropriate to attach a test case into a bug report instead of posting html sources...
Serge is correct. Attachment following this update.
Test this testcase using both latest Mozilla and IE. Why don't the classic param values like <param name="movie" value=".../something.swf"> work? It sort of works, because if you right click over the grey area, you get a Flash context menu. This attachment uses base href="http://www.macromedia.com"
Basically, using testcases, etc., we want to know here: is this Flash's issue? If so, why? Are we passing right array/data structure of params and attributes? are they not loading properly? ActiveX control passes my test case.
The thing does not work for me even if you write the classic <embed>.
Arun, this is possible that the server does not feed us back with the data content because we don't set the referrer URL, see bug 157796. Can you try to create another test case on some other server? The bug is now fixed but any local test case may still fail because server may allow only itself as the referrer.
Note that *some* of the params work, like background color, etc. But others do not work, notably the <param name="movie" ... > which is how to invoke Flash with param. Why do some work and others don't? I'll also attach the SWF file.
Save this file as WillHomeDetail.swf -- it is of type application/x-shockwave-flash and is used exclusively to go along with the HTML test case entered previously.
I think I found the problem. It looks pretty serious. Let's use words 'attribute' and 'param' strictly, first meaning the tag attribute, like <object attrname="attrvalue">, while the latter meaning the tag parameter, like <object ...><param name="paramname", value="paramvalue"></object> We pass to the plugin all necessary tag attributes/params in NPP_New call in one array, there is no problem with that. But later we only create a data stream if we have 'data' or 'src' attribute, ignoring possible 'data' param. The stream never initiates in such a case. As for the attributes, 'data' (or 'src' for embed tag) are standard, we check for them and if found start the stream. There are no standard param names in HTML spec. Should we treat <param name="data"> as standard too and trigger the stream initiation process upon finding it? Probably not. Plugin should request it based on the info it gets in NPP_New call, rather than rely on automatic stream creation as in the case of having 'data' attribute. Thoughts?
Let me try to explain the two scenarios. Scenario I: <object type="mimetype" data="dataurl"></object> 1. in NPP_New call the plugin gets two name/value pairs: name[0]="type", value[0]="mimetype" name[1]="data", value[1]="dataurl" (we also duplicate "data" as "src" but this is not relevant now) 2. "data" attribute has standard meaning for the object tag, so Mozilla takes it as the data source URL and starts the data stream to the plugin automatically 3. plugin plays the data Scenario II: <object type="mimetype"><param name="data" value="dataurl"></object> 1. in NPP_New call the plugin gets three name/value pairs: name[0]="type", value[0]="mimetype" name[1]="PARAM", value[0]="" name[2]="data", value[2]="dataurl" note the second pair with empty value, that's how the plugin knows that all the following pairs come from <param> tags rather than the object tag attribute 2. Mozilla does not see any reserved for data source URL attributes and does NOT start the data stream to the plugin 3. plugin should understand that this is going to happen and request the data via NPN_GetURL call to Mozilla, so Mozilla can initiate the stream Does it all make sense? Evangelize?
Andrei: this sounds pretty evil, but what I don't understand is if we know that the values past the null param value are param attribute values, why can't we take the initiative to pass the data attribute value via NPN_GetURL? Or am I totally off the mark here?
we can always do a hack if there is no "src" or "data" attributes by parsing the value of params, if we find something which looks like filename+ ext corresponding to given mimetype, we can consider that param name equals to "data". But that would be a hack, and av is right, plugin itself suppose to parse its params and request the stream from us if needed.
Beth: NPN_GetURL is something the plugin calls on us, not us calling to the plugin. That's how plugins ask for data. We pass all the params/attrs to the plugin in NPP_New which is the first call to the plugin instance. We cannot take any initiative without having a guess first. This is not the case with attributes where we know exactly what the word 'data' means -- it specified in the HTML spec. In the <param> list it can be anything, Flash uses 'movie' (?) e.g. It will be really hard to guess by the param name, so we will need to look at the value, which can also be unrecognizable, especially when it is relative location (lacks protocol scheme), file without extension etc. So, the real question is: should we follow the spec and rely on plugin to sort out the situation or should we go smart and try to decide what plugin wants (and still fail)? Would be good to know how ActiveX version of Flash works in this kind of situation. Does IE play 'smart' or does Flash take the lead?
I see, I understand, it sounds as though we should let the plug-in perform its own analysis.
Reassigning to aruner as it seems to be more of evangelizm issue. Arun, if you think we should go ahead and 'fix' this by introducing a hack, give it back to me.
Assignee: av → aruner
OK, so I guess everyone can confirm that the fix to bug 152334 has nothing to do with all this? In fact, what I want to know is that what we pass to Flash *has not changed at all* and that this is the way we've always passed attributes and params? One factor which makes this look like an evangelism bug is the fact that *other plugins* such as that mentioned by shrir work with param tag invocations to the plugin. Only Flash does not work with param passing. But I'm looking for *absolute* confirmation that we didn't break parameter passing.
Correct. Bug 152334 is about adding one more artificial attribute which clones DATA attribute but has SRC name. As for params passing -- no, nothing changed since a while ago when we added params to what we pass to the plugin. If we broke params passing, then the same HTML would work with the same Flash in older Mozilla versions. Is this the case?
I've created some additional test cases that demonstrate this bug is not confined to Flash, and seems to occur with most, but not all plugins. So far, I've found that AlternaTIFF, Cortona, SpinFire, and Quicktime all exhibit the same behavior. As noted above, Media Player doesn't suffer this problem. (Tested using build 2002072608, just downloaded and installed today.) Using the data attribute at first seems standards-compliant, but once you add in a codebase attribute for XPIinstall, data takes the codebase URL as its base for relative URLs. This causes the plugin to go looking for the author's content on the plugin-vendor's site--a big problem. Also, since the HTML spec states the following in section 13.3, it seems to me that support for <param name="src" ...> is really needed. As for comment #15, while there is no standard, all of the IE controls or plugins I've tested (including Flash) accept <param name="src" ...> instead of "movie", or whatever else the vendor shows in their examples. "This document does not specify the behavior of OBJECT elements that use both the classid attribute to identify an implementation and the data attribute to specify data for that implementation. In order to ensure portability, authors should use the PARAM element to tell implementations where to retrieve additional data." The question is, though, is it the plugin vendors that aren't doing this right in the Netscape plugins, or is it a bug in the current Moz code? If the former, should any <param name="src" ...> value be passed to the plugins as a fake src attribute? Plugins using <param name="src" value="myfile.ext" />: http://www.cadenceweb.com:8080/newsletter/sheerin/test/Quicktime.html http://www.cadenceweb.com:8080/newsletter/sheerin/test/SpinFire.html http://www.cadenceweb.com:8080/newsletter/sheerin/test/VRML.html http://www.cadenceweb.com:8080/newsletter/sheerin/test/TIFF.html Plugins using the data="myfile.ext" attribute: http://www.cadenceweb.com:8080/newsletter/sheerin/test/Quicktime-data.html http://www.cadenceweb.com:8080/newsletter/sheerin/test/SpinFire-data.html http://www.cadenceweb.com:8080/newsletter/sheerin/test/VRML-data.html http://www.cadenceweb.com:8080/newsletter/sheerin/test/TIFF-data.html
IMHO we cannot tweak any param/value pair even if value is looking like a value for src param,we never know what content/plugins provider means by that param/value pair. here is the simple scenario: I'm content provider using <param name="movie" value="../file"> ... <param seek="start" value="N"> and it means my plugin will seek in ../file from the beginning of the file N string and N-1 string is contains actually URI to content which my plugin is going to handle. If mozilla changes <param name="movie" to "src" my plugin is screwed:( so I wouldn't do anything with the content except evangelized it's provider.
Keywords: html4, testcase
Whiteboard: [adt1] [PL2:NA] [ETA Needed] → [adt1] [PL2:NA] [ETA Needed][HTML4-13.3.2]
Marking as topembed+. We should compatible with other browsers and how they interact with plugins.
Keywords: topembed → topembed+
Whiteboard: [adt1] [PL2:NA] [ETA Needed][HTML4-13.3.2] → [adt1] [PL2:NA] [HTML4-13.3.2]
Jaime: we are passing the param name/value pairs to the plug-in, the remaining issue here is from the plug-in vendor to analyze the data and process it as they deem appropriate.
This bug was originally logged saying that some plugins don't support some well-known "invocation" params, especially Flash with <param name="movie" value="somefile.swf">. Flash only works with data attribute to object element, but not with this invocation param element. But we've decided that this is an evangelism issue, and that each vendor must address this problem individually. I've logged bug 180378 to deal with the effort to evangelize Macromedia to fix this issue, and made it a blocker for this bug. We'll use all the good info. in this bug to track vendors that are making these kinds of changes to param. Please log other bugs (for other vendors and other broken "well-known" params) and make them block this bug.
Depends on: 180378
Whiteboard: [adt1] [PL2:NA] [HTML4-13.3.2] → [META][adt1] [PL2:NA] [HTML4-13.3.2]
topembed-
Keywords: topembed+ → topembed-
Whiteboard: [META][adt1] [PL2:NA] [HTML4-13.3.2] → [META] [PL2:NA] [HTML4-13.3.2]
Target Milestone: mozilla1.2alpha → ---
*** Bug 284727 has been marked as a duplicate of this bug. ***
Here are some different situations that Opera tries to handle and I think Firefox should do the same. http://home.tbbs.net/shadow/html/embedding/firefox_plugins_handling.html In addition, when embedding something with the realplayer plugin using the object tag, Firefox doesn't honor any of the params.
I'm using the latest SeaMonkey build on OS X, and I think I see this problem with embedded PDFs. An online bank I use offers PDFS of my statements. When I click on the link to download the statement, a window appears, and the HTML in this window is: <html> <head> <STYLE TYPE="text/css"> BODY {margin: 0pt} </STYLE> <script language="javascript" type="text/javascript" src="/webtrends7/top_section.js"></script> <script language="javascript" type="text/javascript" src="/webtrends7/globaltags.js"></script> <script language="javascript" type="text/javascript" src="/webtrends7/jsversion.js"></script> <NOSCRIPT> <IMG BORDER="0" NAME="DCSIMG" WIDTH="1" HEIGHT="1" SRC="http://www1.member-hsbc-group.com/dcseu97yi000004j50cqv75nm_8z8y/njs.gif?dcsuri=/nojavascript&WT.js=No"> </NOSCRIPT> <BODY TOPMARGIN="0" LEFTMARGIN="0" MARGINWIDTH="0" MARGINHEIGHT="0"> </head> <body> <object id="pdfObj" type="application/pdf" width="100%" height="100%"> <param name="src" value="cchrs_Download_Data.jsp"> </object> <img id="wusage" src="/images/trk_cc204_PdfStmt.gif" width="1" height="1" border="0" alt="" /> <script> document.pdfObj.SetZoom(100); </script> <script language="javascript" type="text/javascript" src="/webtrends7/bottom_section.js"></script> </body> </html> The Window is blank, however. The funny thing is that I have the same problem with Safari and IE on OS X, so technically I guess it's not a SeaMonkey problem, but that doesn't really help me a whole lot.
Embedding Flash While Supporting Standards http://www.alistapart.com/articles/flashsatay Embedding with using Param http://service.real.com/help/library/guides/realone/ScriptingGuide/HTML/htmfiles/embedint.htm#tags Severity was set to critical but this is not justified; critical is for "crashes, loss of data, severe memory leak". Setting severity to Major I'm voting for this bug
Severity: critical → major
If I understand correctly, Gecko-based browsers already support data attribute. I even wonder why severity should be "Major" here... Object Embedding (Flash) http://wiki.dreamhost.com/index.php/Object_Embedding#Flash
QA Contact: shrir → plugins
The documentation of Adobe stats: "movie ([in element] param) - Specifies the source location (URL) of the SWF file to load". http://kb2.adobe.com/cps/127/tn_12701.html#main_Required_attributes To me it seems, that the attribute "data" is NOT of any relevance to Flash. And in fact the following HTML code doesn't work in Mozilla Firefox. But it really works in Opera and Chrome. Please don't forget that all three browsers are using the very same dll when handeling Flash content. <object type="application/x-shockwave-flash"> <param name="movie" value="http://www.w3schools.com/html/bookmark.swf"> </object> BTW: Quicktime movies embedded with <object> are playing well in Opera and Chrome, but are rejected in Firefox. So, this bug is a serious thread in interoperability.
As well as I understand this report, it is not a bug. <object data="" is not a plugin parameter, is it a required attribute as part of HTML.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → INVALID
(In reply to André Zepezauer from comment #31) > The documentation of Adobe stats: "movie ([in element] param) - Specifies > the source location (URL) of the SWF file to load". > http://kb2.adobe.com/cps/127/tn_12701.html#main_Required_attributes I think that documentation is incomplete and error-prone. One criteria for good documentation is to have a "Test for yourself" link where the reader can check his/her browser and learn interactively how to code. > To me it seems, that the attribute "data" is NOT of any relevance to Flash. In this Adobe document OBJECT tag syntax | Flash Professional http://helpx.adobe.com/flash/kb/object-tag-syntax-flash-professional.html#step_par_text_0 " Edit the attributes of the OBJECT tag for your SWF file. (...) Change all instances of 'movie_name.swf' where it appears in the OBJECT tag above to the actual path or URL of your SWF file. " and it is definitely about the data attribute. And the HTML code provided is almost the same as Object Embedding; 4. Flash http://wiki.dreamhost.com/index.php/Object_Embedding#Flash > And in fact the following HTML code doesn't work in Mozilla Firefox. But it > really works in Opera and Chrome. Please don't forget that all three > browsers are using the very same dll when handeling Flash content. > > <object type="application/x-shockwave-flash"> > <param name="movie" value="http://www.w3schools.com/html/bookmark.swf"> > </object> I went to w3schools.com and found HTML - The <object> Element Adobe Flash Player - Play SWF Video http://www.w3schools.com/html/html_object.asp and then clicked the "Try it yourself" link http://www.w3schools.com/html/tryit.asp?filename=tryhtml_flashobject and it worked in Firefox 18.0.2 without any problem. They use <param name="SRC" ...> instead of the recommended by Adobe <param name="movie" ...> . Inside the wrapping <object>, they nest an <embed src="bookmark.swf" ...> which is, for practical reasons, equivalent to an inner <object data="bookmark.swf" ...> > BTW: Quicktime movies embedded with <object> are playing well in Opera and > Chrome, but are rejected in Firefox. Object Embedding; 2. Video (Quicktime) To embed a Quicktime movie (.mov) file in a webpage: http://wiki.dreamhost.com/index.php/Object_Embedding#Video and the nested, inner <object data="movie.mov" ...> will be processed accordingly by Firefox. The outer, wrapping <object> is processed by older IE versions. > So, this bug is a serious thread in > interoperability. The only serious threat to interoperability is the difficulty or time to search+find good, reliable, updated+verified, web-standards-compliant code, documentation, tutorials with working examples. Gérard
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: