70976 - Add intrinsic sizing support for NPAPI

Status: RESOLVED WONTFIX

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

Description

[Chris Hubick]

If I embed an Object in a web page, without specifying a width or height size,
the object should appear at it's natural size - if it has one.

If I embed a audio/wav with no size, I currently get the default 240x200 frame
size, rather than just what is necessary for the [quicktime] audio player
controls.  Web page authors can not be expected to know or specify how much
space the UI for a sound file takes up on arbitrary browsers.  I should be able
to embed a sound without specifying it's size, and without getting a large gray
box around a nice and tiny [quicktime] UI.

If I embed an SVG file using an Object tag with no size, using Adobe SVG 2.0b4
plugin, I still get the default 240x200 size rather than the inherent/natural
size specified in the SVG file.

I am assuming this is a layout problem rather than a plug-in problem, or a
problem with every plugin I have used without explicit sizing.

Comment 1

[Chris Hubick]

Attachment: Test case, unsized Object tag referencing WAV file

Comment 2

[Keyser Sose]

Confirmed
platform: PC
OS: Linux 2.2.17
Mozilla Build: 2001030108

Marking NEW.

Comment 3

[karnaze (gone)]

Reassigning to av.

Comment 4

[Peter Lubczynski]

Another object frame size issue, possiby a dup.

Comment 5

[basic]

The testcase (attachment 26845 [details]) doesn't seem to work on build 2001061404 win32.

Comment 6

[Peter Lubczynski]

The current plugin API doesn't define a way to specify a "natural" or "defaut"
size so I'm marking this bug as INVALID. There is currently no way for Mozilla
to do this. I agree we don't do this very well right now and I'm working to fix
that so at least it's the same as IE. There is now way we could do what you ask
without inventing a new API call that exsisting plugins won't be able to use anyway.

The best thing to do is NOT to have the plugin's UI visible at all. You should
use Javascript to control the plugin from markup. However, the Quicktime plugin
is currently not scriptable in Mozilla, but Real and Beatnik are.

Comment 7

[Chris Hubick]

This concerns me.  This is very basic and important functionality.

We seem to agree that it is broken, which is good.

I am an HTML purist.  And I teach web design.  All I have ever wanted is the 
ability to construct a modern web page the /right/ way, that is, clean and pure 
structure/presentation separated cross browser/platform HTML which is accesible 
to all, and compliant with the letter and intent of the most recent W3C 
specifications.   Stress the clean part...I don't want anything even resembling 
a "hack" in the HTML code.

I would like to include a looped sound on my web page.  Properly.  And I don't 
want it to look horrible.

People have had sounds on web pages for quite some time now...and with the web 
being this big interactive multimedia oriented platform...well, you would think 
this wouldn't be that hard.

So, according to W3C specs, I should be including my sound using an Object tag, 
fine.  But audio data does not have a visual size.  A browser /may/ choose to 
present it to the user through a GUI, which may have a size - but that is 
decided by the browser, not the page author.  As a web page author, I have no 
idea how much screen space a sound takes up. If any, being that this might be a 
web browser in someones car radio reading the pages to them.  Or on a PDA.  Or 
Mozilla on a 8000x6000 resolution monitor in the year 2008.

So fine, I don't (and can't) specify a size for the Object tag.  It looks 
horrible on Mozilla.

The fault is either in the web page, or the software rendering it.

Are you telling me a web page author can't include sound in HTML without using 
Javascript (or at least the standardized ECMA Script + DOM)?  It is arguable 
that the web page is correct, in that using a simple unsized HTML Object tag 
should be all that is required.

Are you telling me that Mozilla.org is refusing to support the basic 
functionality of including a sound in a web page (through a means consistent 
with the intent of the HTML 4 specification) without rendering it in a visually 
displeasing manner?

Being that I only construct pure web pages, this basically means "Mozilla 
doesn't do sound".

At the very minimum this should be changed to FUTURE or at least WONTFIX.

Comment 8

[Peter Lubczynski]

>> But audio data does not have a visual size.  A browser /may/ choose to 
>> present it to the user through a GUI, which may have a size - but that is 
>> decided by the browser, not the page author.

You are right about audio not having a visual size. In these cases, in fact all
the ones where an HTML author does not specify a width or a height on the OBJECT
tag, we should default to zero like IE does instead of the random value we
choose now. The browser does not display the GUI, the plugin usually draws
directly to the screen.

>> The fault is either in the web page, or the software rendering it.

You are also right that the problem is with the software rendering it, however,
that software is not the browser. The problem is with the plugin, but more
specifically the plugin API. When using the OBJECT tag to display multimedia,
the browser is simply an agent and you are at the mercy of the plugin installed
for that mime-type. In order for intrinsic sizing to work, the plugin would need
to somehow communicate it's desired size back to the browser and we currently
have no facility to do this. Plugins usually don't live up to the strict
specifications of the W3C as a browser (although that may change), so I don't
see this changing anytime soon.

I think the right way to do this now may be to specify a width & height of zero
and use standardized ECMA Script + DOM to control playback through your own GUI.
 But if you REALLY want this to work, you can write your own plugin and
implement intrinsic sizing through the ECMA Script + DOM.

Comment 9

[shrirang khanzode]

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

Comment 10

[Peter Lubczynski]

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

Comment 11

[Chris Hubick]

> In order for intrinsic sizing to work, the plugin would
> need to somehow communicate it's desired size back to the
> browser and we currently have no facility to do this.

After my great surprise that this functionality doesn't exist already... I 
think shipping frozen plugin API's for 1.0 with this limitation is a big 
mistake.  If an API call for this isn't added and documented now, I highly 
doubt it will be added or used for a very long time to come.

I would expect /every/ plugin author to want this functionality???  It is 
arguable that aside from the basic box model component of the layout, display 
of all objects (images, sound, etc) should be conducted through a plugin API.  
The HTML 'img' tag was a mistake - the 'object' tag should really have been 
used for this.

I think a baseline requirement for a shipping plugin API is that it should be 
able to handle 'img' tag support for the browser.  Unless you consider it 
valid behavior for the browser to not display (0 size) an image without 
explicit width and height in the HTML - which would break 99% of pages on the 
web.  Aside from all the problems from the HTML authors point of view, which I 
have already covered, I should be able to write a plugin able to display my 
new image format and have it work in the same way is the integral image 
support.  Adobe should be able to have their SVG plugin size to that reported 
by the SVG viewport parameter in the XML Data.  And the Quicktime plugin 
should be able to size itself according to it's GUI.  etc, etc, etc.

I am reopening this, and moving from Layout to Plug-In's because I think it is 
a reasonable request that at least deserves more consideration.  Someone might 
want to change the title to "Support an API call for intrinsic sizing by 
plugins".

Comment 12

[Peter Lubczynski]

The depricaded XPCOM Plugin API did provide a way to do this through
nsIPluginInstancePeer::SetWindowSize(w,h) but looks like it's never been
implemented.

For the NPAPI, perhaps we can add two NPPV variables to NPP_GetValue for
intrinsic sizing. Layout would call these to figure out how big the plugin would
like to make itself. Plugins which didn't implement the varibles would get a
default size. 

I'm not sure there is time before Mozilla 1.0 to implement such a change.
However, Mozilla does accept patches from outside contributors.

Comment 13

[av (gone)]

There was a plan to do such a thing long time ago. I will attach a document
which described the desired feature. And it is at least partially implemented,
the appropriate values are in the npapi.h file.

Comment 14

[av (gone)]

Attachment: Document describing a plan to implement dynamic plugin sizing

Comment 15

[Peter Lubczynski]

Setting PL2:P3, this is a desireable feature for plugin vendors for cases when
the markup specifies no size

Comment 16

[Marek Z. Jeziorek]

batch: adding topembed per Gecko2 document
http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html

Comment 17

[Jaime Rodriguez, Jr.]

Topembed+ as this is needed by Gecko 2.0 and a major embedding customer.

Comment 18

[Brant Gurganus]

[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.

Comment 19

[rubydoo123]

moving to 1.4 beta, Plug-in branch work

Comment 20

[Peter Lubczynski]

per topembed+ triage: topembed-, nsbeta1-, Future

Comment 21

[Calvin Spealman]

This can't be such a difficult thing to fix. Why is it taking so long? I'm sure
most would reply, "So, fix it yourself!", but, I'm just curious.

Comment 22

[Calvin Spealman]

would it be possible to do this without putting it in the hands of the plug-in?
to check the size of the plug-in after it is initialized and adjust accordingly?

Comment 23

[Boris Zbarsky [:bzbarsky]]

Plugin initialization involves the plugin being told how much space it has. 
That's part of the plugin API and not easily subject to change.

What could perhaps be changed is to add a new function to the plugin API to
allow us to ask the plugin how much space it _would_ want, and then passing it that.

As for how hard this is to do, I have no idea how it would be done.  Do you? 
Please don't claim things are easy to do if you don't know how to do them -- it
just makes you look foolish.

Comment 24

[Josh Aas]

We're not going to do this, it just isn't a priority. If you control the content on your page then you have plenty of options, from specifying a size in the tag for the plugin to dealing with this via NPRuntime scripting (your page can ask the plugin what size it'd like). If you don't control the content, you're just loading random plugins because you can and you don't know how big they should be, that's not a use case I'm interested in supporting.