Closed Bug 8740 Opened 25 years ago Closed 24 years ago

The default size for unsized OBJECTs should be larger

Categories

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

defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: Antti.Nayha, Assigned: serhunt)

References

()

Details

(Keywords: html4, Whiteboard: Fix in hand [nsbeta3+])

TESTED ON: both M7 and the 06-22-10-M8 nightly build SEE ALSO: http://www.student.oulu.fi/%7esairwas/object-test/video/qt2.html (an identical copy of the test, only in Quicktime format) This page has an AVI video OBJECT with no width and height attributes whatsoever. Mozilla does load the video, but it doesn't render anything - ie. it acts like both the width and height attributes had a value of "0". Not even the alternative content is displayed. A correct way to handle this would be to render the OBJECT in its natural size - in this case, 160x120 pixels. Is this even possible with the current plug-ins and Mozilla's plug-in architecture? I suppose this will be hard to implement, if the plug-ins don't even pass the size of the video clip to the browser. Note that some video player plug-ins - like Quicktime 3 - add all kinds of control bars to the OBJECT. In the case of QT3, the OBJECT's rendered size should be sized 160x136 pixels instead of 160x120 (see a screenshot at http://www.student.oulu.fi/%7esairwas/object-test/video/qt3video.png). Because of this, it seldom makes any sense to specify a video OBJECT's size with the HTML attributes; the author cannot possibly know by which plugin the video clip will be rendered on the user agent.
Sorry about the long lines, I guess that was a bug in my Opera 3.60. Reposting. --------------------------------------------------------------------- TESTED ON: both M7 and the 06-22-10-M8 nightly build SEE ALSO: http://www.student.oulu.fi/%7esairwas/object-test/video/qt2.html (an identical copy of the test, only in Quicktime format) This page has an AVI video OBJECT with no width and height attributes whatsoever. Mozilla does load the video, but it doesn't render anything - ie. it acts like both the width and height attributes had a value of "0". Not even the alternative content is displayed. A correct way to handle this would be to render the OBJECT in its natural size - in this case, 160x120 pixels. Is this even possible with the current plug-ins and Mozilla's plug-in architecture? I suppose this will be hard to implement, if the plug-ins don't even pass the size of the video clip to the browser. Note that some video player plug-ins - like Quicktime 3 - add all kinds of control bars to the OBJECT. In the case of QT3, the OBJECT's rendered size should be sized 160x136 pixels instead of 160x120 (see a screenshot at http://www.student.oulu.fi/%7esairwas/object-test/video/qt3video.png). Because of this, it seldom makes any sense to specify a video OBJECT's size with the HTML attributes; the author cannot possibly know by which plugin the video clip will be rendered on the user agent.
Status: NEW → ASSIGNED
Target Milestone: M9
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
I fixed this making it work like in 4.x But I think we have more general problem with plugins now, so verifying this may be not easy
Status: RESOLVED → REOPENED
I tried this on a win98 system using the 1999080908 build and nothing rendered, just to make sure I tried it on nav 4.7 and it did work.
Resolution: FIXED → ---
If you see a small window (when size is not specified) but no video, that's what I am currently excpecting. It is not fed with video stream, but this is another issue.
I don't get anything -- nada -- just a big open white space
You are right, my fault. Just checked in the fix. Now you should see a window with some default size.
no problem -- I'll wait till Wednesday to recheck it
Status: REOPENED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
I'll mark it resolved to get it out of M9 radar.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
using the 1999082016 build -- what I get is the alt text -- since I don't get the box, I'm reopening the bug
Hm... I see the box in todays pull. And the size seems to be ok. Are you sure you did not forget to copy the plugin over?
My 1999082316 Apprunner on Win95 shows a blank white space - neither alt text, box nor video.
This could be possible, but you should be able to "see" the window using Spy.
Target Milestone: M9 → M10
Will not hold M9 for this. Will release note if found to be a reproducible problem. Moving to 10.
no, I just tried it again using the 1999082016 build and yes I have the plugin installed -- it is in the default directory (Program Falls|JavaSoft|Jre|1.2.2) -- which shouldn't be a problem. I get the same result, just the alt text
hmm, I just checked all of the video tests and none of them work
I have it in plugins dir under where we have the executable. If you get an alt text this means that the plugin is not invoked at all, like it is not seen by the browser. Video tests should not work now because of 11376
Status: REOPENED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
I'm going to probably give you more information than you care to know -- but here goes. This is how I have my directory set up: Program Files Netscape Program Plugins x86rel JavaSoft Jre 1.2.2 When I launch seamonkey and look at any of the test cases -- there is nothing -- just the alt text. So, I copied the plugins directory from the Program subdirectory into the x86rel subdirectory and then the blocked area appears. However, when I copy the Plugins directory I get an error message in the command window: JavaScript error: Package java defined twice ? so, with the plugins directory in the x86rel subdirectory, this does indeed work as described. Marking this little guy fixed/verified.
Status: RESOLVED → VERIFIED
(I wrote about this in netscape.public.mozilla.plugins 2 weeks ago, but there wasn't really that much discussion, so here goes.) To solve this problem correctly, Mozilla/NS6 must 1) ship with plugins that communicate the object's size to the browser, and 2) be able to size OBJECT elements according to that information. Since we want to be backwards compatible, we should still try and do our best even if the plugin doesn't communicate the size information. This is why the default size for an unsized OBJECT should be much bigger.  The Nav4-legacy 50*50 is clearly ridiculous - I doubt there is _one_ that small video clip in the Web, and many audio player controls won't fit in that space either. I'd vote for something really big, eg. 500*350 - or maybe even something like {width: 100%; height: 350px} in CSS terms. IMHO it's much better to have some extra whitespace on the page than crop the object to 50*50. The default size is important, because in most situations the best way to embed audio or video is an _unsized_ OBJECT. Specifying size explicitly makes usually no sense, since the document author cannot know if the client wants to display some kind of a graphical control bar together with the OBJECT (and if it does, the author cannot know the size of the bar). One day Web authors will start using the preferred (=unsized) type of OBJECT when embedding multimedia, and users with legacy plug-ins will see these cropped to the default size. Luckily, making the default size larger won't break any existing Web pages, because nobody is relying on a 50*50 default size for his/her embedded video. I'm reopening this bug and adjusting summary. (Or should I just have filed a new one? :-/) Also nominating for nsbeta3. Platform/OS are most probably All/All. PS. It's also extremely important to inform plug-in authors about this problem - it seems that most of the popular plugins, eg. Quicktime Player, don't currently pass the object size to the browser. Correct me if I'm wrong.
Status: VERIFIED → REOPENED
Keywords: nsbeta3
OS: Windows NT → All
Hardware: PC → All
Resolution: FIXED → ---
Summary: Video clips aren't rendered if no size is specified → The default size for unsized OBJECTs should be larger
Keywords: html4
correctness of display for plug-ins. Plug-in default size should not be 0,0--that's a nonsensical value to pick, the user sees nothing, and it breaks cross-browser compatibility of support for the OBJECT tag.
Keywords: correctness
Last time I checked, the default size was 50*50 - which is consistent with Nav 4.x, but nearly as useless as 0*0.
hmm, I should not be QA contact, am reassigning
QA Contact: beppe → shrir
Shrirang, do you know what plugin is capable of rendering this mime type (vide/x-msvideo)?
Status: REOPENED → ASSIGNED
OK, this one work correctly with QuickTime on the following link: http://www.student.oulu.fi/%7esairwas/object-test/video/qt2.html And it does no worse than 4.x Eric, does it mean I can mark it fixed?
Hi Andrei -- If you think a bug is fixed, please mark it fixed and QA will verify. You can also mark the verifyme keyword (as I just did) to solicit external verification if you wish. I trust your judgment. (I'm also too swamped right now! ;-> )
Keywords: verifyme
The default size must be larger than 50*50; something like the CSS {width: 100%; height: 350px} would be nice. See my 2000-06-27 comment.
Keywords: verifyme
Lowering Severity to Normal.
Severity: major → normal
Andrei, quicktime and Cineweb (by Digigami) support the mime type video/x-msvideo.
You can kill me but I don't see it in the list of mime types when I do about:plugins. They could have dropped it in 4.1 what I have on my machine. But this is not relevant. Antti, we should probably increase the object default size I agree, but I would not do it too big. My vote is 200x100. In the new world all this does not look as important as you described in your previous comment, since 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.
Whiteboard: Fix in hand
> 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. Yes, this is the Right Way to embed video on a Web page. In order to be HTML 4.0 compliant, Mozilla/NS6 must ship with _only_ such plug-ins. However, people will still be installing old plug-ins for some time, and not every plug-in manufacturer will be updating its product immediately. For example, Apple hasn't done it for Quicktime yet. (Actually, I haven't so far seen a single plug-in that implements this.) 200x100 is too small; it wouldn't fit the popular 240x180 size (or even 160x120). We need some extra space for the possible plug-in controls too, so something like 240x200 is the minimum, IMHO. That being said, they're even embedding 480x360 videos on Web pages nowadays. :-/
Whatever you do, please just shoot for functional compatibility with the behavior of 4.x on this. We just want to avoid introducing new incompatibilities at this point; we don't want to try to be "smart" and "improve" the product by doing something "better" on this kind of issue because the theoretical benefit of behavior that might be considerd "better" by someone isn't worth the risk of introducing new incompatibilities by changes, especially this close to ship.
I agree about the importance of backwards compatibility. However, as I already stated, compatibility is not an issue here since virtually no Web page today - test sites excluded - uses unsized OBJECTs (that's because most current cannot render them properly).
(...most current _browsers_, that is.)
Approving for nsbeta3
Whiteboard: Fix in hand → Fix in hand [nsbeta3+]
Some further info on existing implementations: Nav 4.x seems to use something like {width: 90%; height: 50%} for unsized Java OBJECTs, which is sensible. For some reason, it uses 50*50 pixels instead when dealing with plug-in OBJECTs. Opera 4.0 uses 350*150 pixels for unsized HTML/plaintext OBJECTs. I've got some trouble with plug-ins in Opera, so I don't know about plug-in OBJECTs yet.
240x200 is in.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago24 years ago
Resolution: --- → FIXED
240*200 is fine, at least for the time being. We're doing a lot better than IE now, anyway. :-) I'd prefer transparent background instead of a grey one, but that's just a matter of taste. Verified on Win32 build 2000-08-09-08 - will verify Mac & Linux RSN.
Verified on Linux (build 2000-09-03-08) - Mac to go.
Verified on Mac (build 2000-09-04-08) - marking Verified/Fixed on all platforms. Now let's just hope that nobody complains about the changed size of unsized Java OBJECTs (which used to be 90%*50% in Nav4; now they're 240*200 like all other OBJECTs).
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.