Closed Bug 70976 Opened 21 years ago Closed 10 years ago
Add intrinsic sizing support for NPAPI
223 bytes, text/html
3.89 KB, text/html
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.
Confirmed platform: PC OS: Linux 2.2.17 Mozilla Build: 2001030108 Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reassigning to av.
Assignee: karnaze → av
Another object frame size issue, possiby a dup.
Assignee: av → peterlubczynski
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
>> 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.
*** Bug 125046 has been marked as a duplicate of this bug. ***
*** Bug 70978 has been marked as a duplicate of this bug. ***
> 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".
Status: RESOLVED → REOPENED
Component: Layout → Plug-ins
Resolution: INVALID → ---
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.
Summary: Embeded OBJECT's should use natural size unless overriden → [RFE] Add intrinsic sizing support for NPAPI
Target Milestone: mozilla0.9.5 → mozilla1.1
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.
Setting PL2:P3, this is a desireable feature for plugin vendors for cases when the markup specifies no size
Status: REOPENED → ASSIGNED
Priority: -- → P3
batch: adding topembed per Gecko2 document http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html
Topembed+ as this is needed by Gecko 2.0 and a major embedding customer.
[RFE] is deprecated in favor of severity: enhancement. They have the same meaning.
Severity: normal → enhancement
Summary: [RFE] Add intrinsic sizing support for NPAPI → Add intrinsic sizing support for NPAPI
moving to 1.4 beta, Plug-in branch work
Whiteboard: [PL2:P3] [adt2] [ETA Needed] → [PL:BRANCH]
Target Milestone: mozilla1.3alpha → mozilla1.4beta
per topembed+ triage: topembed-, nsbeta1-, Future
Attachment #26845 - Attachment description: Test case, unzised object tag referencing wav file → Test case, unsized Object tag referencing WAV file
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.
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?
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.
Assignee: peterlubczynski-bugs → nobody
Status: ASSIGNED → NEW
QA Contact: chrispetersen → plugins
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.
Status: NEW → RESOLVED
Closed: 20 years ago → 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.