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)
Core Graveyard
Plug-ins
Tracking
(Not tracked)
VERIFIED
FIXED
M10
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.
Reporter | ||
Comment 1•25 years ago
|
||
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: 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
Updated•25 years ago
|
Status: RESOLVED → REOPENED
Comment 3•25 years ago
|
||
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.
Updated•25 years ago
|
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.
Comment 5•25 years ago
|
||
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.
Comment 7•25 years ago
|
||
no problem -- I'll wait till Wednesday to recheck it
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Updated•25 years ago
|
Status: RESOLVED → REOPENED
Updated•25 years ago
|
Resolution: FIXED → ---
Comment 9•25 years ago
|
||
using the 1999082016 build -- what I get is the alt text -- since I don't get
the box, I'm reopening the bug
Assignee | ||
Comment 10•25 years ago
|
||
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?
Reporter | ||
Comment 11•25 years ago
|
||
My 1999082316 Apprunner on Win95 shows a blank white space - neither alt text,
box nor video.
Assignee | ||
Comment 12•25 years ago
|
||
This could be possible, but you should be able to "see" the window using Spy.
Comment 13•25 years ago
|
||
Will not hold M9 for this. Will release note if found to be a reproducible
problem. Moving to 10.
Comment 14•25 years ago
|
||
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
Comment 15•25 years ago
|
||
hmm, I just checked all of the video tests and none of them work
Assignee | ||
Comment 16•25 years ago
|
||
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
Updated•25 years ago
|
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Comment 17•25 years ago
|
||
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.
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 18•24 years ago
|
||
(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
Comment 19•24 years ago
|
||
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
Comment 20•24 years ago
|
||
Last time I checked, the default size was 50*50 - which is consistent with Nav
4.x, but nearly as useless as 0*0.
Assignee | ||
Comment 22•24 years ago
|
||
Shrirang, do you know what plugin is capable of rendering this mime type
(vide/x-msvideo)?
Assignee | ||
Comment 23•24 years ago
|
||
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?
Comment 24•24 years ago
|
||
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
Comment 25•24 years ago
|
||
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
Comment 27•24 years ago
|
||
Andrei, quicktime and Cineweb (by Digigami) support the mime type
video/x-msvideo.
Assignee | ||
Comment 28•24 years ago
|
||
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.
Comment 29•24 years ago
|
||
> 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.
:-/
Comment 30•24 years ago
|
||
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.
Comment 31•24 years ago
|
||
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).
Comment 32•24 years ago
|
||
(...most current _browsers_, that is.)
Comment 34•24 years ago
|
||
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.
Assignee | ||
Comment 35•24 years ago
|
||
240x200 is in.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED
Comment 36•24 years ago
|
||
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.
Comment 37•24 years ago
|
||
Verified on Linux (build 2000-09-03-08) - Mac to go.
Comment 38•24 years ago
|
||
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
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•