mozilla
您的搜索结果

    关于插件的基本知识

    插件的用处

    插件提供了丰富的特性,能让基于Gecko的浏览器更灵活。如今有很多这样的插件:

    • 多媒体查看器,像Adobe Flash 和 Adobe Acrobat
    • 提供object元素嵌入以及压缩解压缩服务的通用组件
    • 应用程序(从个人信息管理工具到游戏,都有)
    能够创造新颖并且富有创意的插件的作者越来越多,这让插件的使用范围看起来大到没有边际
    使用Plug-in API,你创造的动态加载的插件能够做如下:
     
    • 注册一个或多个MIME类型
    • 在浏览器窗口的一部分里进行绘画
    • 截获键盘和鼠标的事件(并进行相应处理)
    • 使用URL获取网络数据
    • 向一个URL提交POST请求
    • 添加指向新URLs的超链或热点
    • 在HTML页面的section中进行绘制
    • 让native code和 JavaScript/DOM 通信

     

    你可以通过“安装插件”页查看已经安装在造作系统上并和浏览器关联的插件。在地址栏输入“about:plugins”。安装插件页面罗列了每个安装的插件,以及他们的类型和MIME类型、描述、文件扩展,还有他们当前和MIME类型关联的状态(允许或禁止)。注意显示源代码功能就是通过javascript收集的信息。
     
    因为插件是平台相关的,你必须将他们移植所有操作系统和处理器平台上,当然这取决于你想在哪个平台部署你的插件。

     

    插件和helper程序

     
    在正式进入插件部分前,还应该了解helper程序。helper程序是分离的、独立的。并且能从浏览器启动。和插件一样,当遇到一个MIME类型时浏览器会启动该类型对应的helper程序。但它不同于插件,helper程序独立于浏览器在其自己的空间中运行,而且不与浏览器和web交互。
     
    当浏览器遇到一个MIME类型,它通常会先查找注册的插件。如果没有和MIME类型匹配的插件,它就寻找相应的helper程序。
     
    插件和helper程序满足了不通的需要。
     

    插件如何工作

     
    一个插件的生命周期不向一个程序,它完全被调用的网页控制。这部分将介绍浏览器如何操纵插件。
     
    当Gecko启动,它开始在操作系统的特定目录寻找插件模块。更多关于Gecko如何在不同操作系统寻找插件模的信息,见How Gecko Finds Plug-ins
    当用户打开一个包含媒体类型的嵌入数据时会调用插件,浏览器会通过以下一系列动作来响应:
     
    • 检查MIME类型匹配的插件
    • 将插件的代码加载进内存
    • 初始化插件
    • 创建一个新的插件实例
     
    Gecko能同时在一个页面或几个打开的窗口中加载多个同一插件的实例。举个例子:如果你浏览一个有几个嵌入式RealAudio片段的页面,浏览器会根据需要来创建多个RealPlayer插件实例(虽然同一时间播放多个RealAudio文件多数时候会显得很二:-P )。当用户离开页面或者关闭窗口时,插件实例将被销毁。当最后一个插件的实例被销毁,浏览器会将插件的代码从内存中卸载。当插件没有加载时除了磁盘空间不会使用任何其他资源。下一部分,运行时模型将更具体的描述这些过程。
     

    理解运行时模型
     

    插件是和一个或多个MIME类型关联的动态代码模型。当浏览器启动,它会枚举可以访问的插件(这个过程因平台而各有差异),读取每个插件的资源文件来判断其对应的MIME类型,然后为MIME类型注册插件。


    以下大致描述了插件从加载道销毁的生命过程:

    • 当Gecko遇到注册了的MIME类型数据时(不论是嵌入在HTML页面还是在一个单独的文件中),如果相应的插件没有被加载,浏览器会自动的将插件代码加载进内存,并且创建一个插件的实例。
       

    当插件代码第一次被加载时,Gecko会调用插件API函数 NP_Initialize 。按照惯例,所有特定的插件函数都有前缀“NPP”,所有浏览器相关的函数都有前缀“NPN”。

    Note: 技术上来说 NP_Inilialize和NP_Shutdown 并不是插件传递给浏览器的函数表的一部分。浏览器只在加载和卸载插件的时候调用他们。These functions are exported from the plug-in DLL and accessed with a system table lookup,这意味着他们并不和特定的插件实例关联。更多关于initializing和destructing的信息见Initialization and Destruction

    • 当插件实例化时浏览器会调用NPP_New函数。如果一个页面有多个嵌入对象,或几个开启的浏览器窗口都有同样的数据类型(MIME类型),多个插件实例就会同时存在。
    • 当用户离开插件实例的页面或者关闭窗口,插件实例就被销毁;Gecko调用NPP_Destroy去通知插件实例正在被销毁。
    • 当插件的最后一个实例被销毁后,插件的代码从内存中卸载。Gecko调用NP_Shutdown。插件在不加载的时候不使用任何资源(除了磁盘空间)。

    Note: Plug-in API 的call和callbacks 使用 main Navigator线程。通常,如果你想在插件的生命周期中产生额外的线程去处理流程,你应该保证这些和Plug-in API call的分离。

    查看更多关于这些方法的信息见Initialization and Destruction

    Plug-in detection

    Gecko looks for plug-ins in various places and in a particular order. The next section, How Gecko Finds Plug-ins, describes these rules, and the following section, Checking Plug-ins by MIME Type, describes how you can use JavaScript to locate plug-ins yourself and establish which ones are to be registered for which MIME types.

    How Gecko finds plug-ins

    When a Gecko-based browser starts up, it checks certain directories for plugins, in this order:

    Windows
    • Directory pointed to by MOZ_PLUGIN_PATH environment variable.
    • %APPDATA%\Mozilla\plugins, where %APPDATA% denotes per-user Application Data directory.
    • Application directory\plugins, where Application directory is a directory where the application is installed.
    • Plug-ins within toolkit bundles.
    • Profile directory\plugins, where Profile directory is a user profile directory.
    • Directories pointed to by HKEY_CURRENT_USER\Software\MozillaPlugins\*\Path registry value, where * can be replaced by any name.
    • Directories pointed to by HKEY_LOCAL_MACHINE\Software\MozillaPlugins\*\Path registry value, where * can be replaced by any name.
    Mac OS X
    • Application directory/plugins, where Application directory is a directory where the application is installed.
    • ~/Library/Internet Plug-Ins.
    • /Library/Internet Plug-Ins.
    • /System/Library/Frameworks/JavaVM.framework/Versions/Current/Resources.
    • Plug-ins within toolkit bundles.
    • Profile directory/plugins, where Profile directory is a user profile directory.
    Linux
    • Directory pointed to by MOZ_PLUGIN_PATH environment variable.
    • ~/.mozilla/plugins.
    • Application directory/plugins, where Application directory is a directory where the application is installed.
    • /usr/lib/mozilla/plugins (on 64-bit systems, /usr/lib64/mozilla/plugins is used instead).
    • Plug-ins within toolkit bundles.
    • Profile directory/plugins, where Profile directory is a user profile directory.

    To find out which plug-ins are currently installed visit about:plugins. Gecko displays a page listing all installed plug-ins and the MIME types they handle, as well as optional descriptive information supplied by the plug-in.

    On Windows, installed plug-ins are automatically configured to handle the MIME types that they support. If multiple plug-ins handle the same MIME type, the first plug-in registered handles the MIME type. For information about the way MIME types are assigned, see Registering Plug-ins.

    Checking plug-ins by MIME type

    The enabledPlugin property in JavaScript can be used to determine which plug-in is configured for a specific MIME type. Though plug-ins may support multiple MIME types and each MIME type may be supported by multiple plug-ins, only one plug-in can be configured for a MIME type. The enabledPlugin property is a reference to a Plugin object that represents the plug-in that is configured for the specified MIME type.

    You might need to know which plug-in is configured for a MIME type, for example, to dynamically create an object element on the page if the user has a plug-in configured for the MIME type.

    The following example uses the JavaScript to determine whether the Adobe Flash plug-in is installed. If it is, a movie is displayed.

    // Can we display Adobe Flash movies?
    var mimetype = navigator.mimeTypes["application/x-shockwave-flash"];
    
    if (mimetype) {
       // Yes, so can we display with a plug-in?
       var plugin = mimetype.enabledPlugin;
       if (plugin) {
          // Yes, so show the data in-line
          document.writeln("Here\'s a movie: <object data='mymovie.swf' height='100' width='100'></object>");
       } else {
          // No, so provide a link to the data
          document.writeln("<a href='mymovie.swf'>Click here</a> to see a movie.");
       }
    } else {
       // No, so tell them so
       document.writeln("Sorry, can't show you this movie.");
    }
    

    Overview of plug-in structure

    This section is an overview of basic information you will need as you develop plug-ins.

    Understanding the plug-in API

    A plug-in is a native code library whose source conforms to standard C syntax. The Plug-in Application Programming Interface (API) is made up of two groups of functions and a set of shared data structures.

    • Plug-in methods are functions that you implement in the plug-in; Gecko calls these functions. The names of all the plug-in functions in the API begin with NPP_, for example, NPP_New. There are also a couple of functions (i.e., NP_Initialize and NP_Shutdown), that are direct library entry points and not related to any particular plug-in instance.
    • Browser methods are functions implemented by Gecko; the plug-in calls these functions. The names of all the browser functions in the API begin with NPN_, for example, NPN_Write.
    • Data structures are plug-in-specific types defined for use in the Plug-in API. The names of structures begin with NP, for example, NPWindow.

    All plug-in names in the API start with NP. In general, the operation of all API functions is the same on all platforms. Where this varies, the reference entry for the function in the reference section describes the difference.

    Plug-ins and platform independence

    A plug-in is a dynamic code module that is native to the specific platform on which the browser is running. It is a code library, rather than an application or an applet, and runs only from the browser. Although plug-ins are platform-specific, the Plug-in API is designed to provide the maximum degree of flexibility and to be functionally consistent across all platforms. This guide notes platform-specific differences in coding for the MS Windows, Mac OS X, and Unix platforms.

    You can use the Plug-in API to write plug-ins that are media type driven and provide high performance by taking advantage of native code. Plug-ins give you an opportunity to seamlessly integrate platform-dependent code and enhance the Gecko core functionality by providing support for new data types.

    The plug-in file type depends on the platform:

    • MS Windows: .DLL (Dynamic Link Library) files
    • Unix: .SO or .DSO (Shared Objects) files
    • Mac OS X: PPC/x86/Universal loadable Mach-O bundle

    Windowed and windowless plug-ins

    You can write plug-ins that are drawn in their own native windows or frames on a web page. Alternatively, you can write plug-ins that do not require a window to draw into. Using windowless plug-ins extends the possibilities for web page design and functionality. Note, however, that plug-ins are windowed by default, as windowed plug-ins are in general easier to develop and more stable to use.

    • A windowed plug-in is drawn into its own native window on a web page. Windowed plug-ins are opaque and always come to the top HTML section of a web page.
    • A windowless plug-in need not be drawn in a native window; it is drawn in its own drawing target. Windowless plug-ins can be opaque or transparent, and can be invoked in HTML sections.

    Whether a plug-in is windowed or windowless depends on how you define it.

    The way plug-ins are displayed on the web page is determined by the HTML element that invokes them. This is up to the content developer or web page author. Depending on the element and its attributes, a plug-in can be visible or hidden, or can appear as part of a page or as a full page in its own window. A web page can display a windowed or windowless plug-in in any HTML display mode; however, the plug-in must be visible for its window type to be meaningful. For information about the way HTML determines plug-in display mode, see "Using HTML to Display Plug-ins."

    The default plug-in

    When a specific plug-in is not registered to handle the media referred to in the HTML, Gecko invokes the default plug-in to help users find and install the right plug-in for that MIME type.

    The blue puzzle piece that appears in the HTML page's plug-in window when the default plug-in loads is meant to signify that the browser is missing a piece that it needs to display or play the requested media.

    image:plugin_puzzle.gif

    How the plug-in HTML element was coded determines what action is taken when the user clicks the plug-in piece. If the browser cannot handle the given MIME type, then the default plug-in checks to see if there is a plug-in referenced in the object element that defines the media. If there is, then thedefault plug-in prompts the user to download that plug-in from the specified location. If a plug-in is not specified in the object element, then the default plug-in looks for child elements, such as other object element, which will provide more specific information about how to handle the specified media type.

    Using HTML to display plug-ins

    When a user browses to a web page that invokes a plug-in, how the plug-in appears (or does not appear) depends on two factors:

    • The way the developer writes the plug-in determines whether it is displayed in its own window or is windowless.
    • The way the content provider uses HTML elements to invoke the plug-in determines its display mode: whether it is embedded in a page, is part of a section, appears on its own separate page, or is hidden.

    This section discusses using HTML elements and display modes. For information about windowed and windowless operation, see Windowed and Windowless Plug-ins.

    For a description of each plug-in display mode, and which HTML element to use to achieve it, go on to Plug-in Display Modes. For details about the HTML elements and their attributes, go on to:

    Plug-in display modes

    Whether you are writing an HTML page to display a plug-in or developing a plug-in for an HTML author to include in a page, you need to understand how the display mode affects the way plug-ins appear.

    A plug-in, whether it is windowed or windowless, can have one of these display modes:

    • embedded in a web page and visible
    • embedded in a web page and hidden
    • displayed as a full page in its own window

    An embedded plug-in is part of a larger HTML document and is loaded at the time the document is displayed. The plug-in is visible as a rectangular subpart of the page (unless it is hidden). Embedded plug-ins are commonly used for multimedia images relating to text in the page, such as the Adobe Flash plug-in. When Gecko encounters the object or embed element in a document, it attempts to find and display the file represented by the data and src attributes, respectively. The height and width attributes of the object element determine the size of the embedded plug-in in the HTML page. For example, this object element calls a plug-in that displays video:

    <object data="newave.avi" type="video/avi" 
            width="320" height="200"
            autostart="true" loop="true">
    </object>
    

    A hidden plug-in is a type of embedded plug-in that is not drawn on the screen when it is invoked. It is created by using the hidden attribute of the embed element. Here's an example:

    <embed src="audiplay.aiff" type="audio/x-aiff" hidden="true">
    

    Note: Whether a plug-in is windowed or windowless is not meaningful if the plug-in is invoked with the hidden attribute.

    You can also create hidden plug-ins using the object element. Though the object element has no hidden attribute, you can create CSS rules to override the sizing attributes of the object element

    object {
      visibility: visible;
    }
    
    object.hiddenObject {
      visibility:   hidden !important;
      width:        0px    !important;
      height:       0px    !important;
      margin:       0px    !important;
      padding:      0px    !important;
      border-style: none   !important;
      border-width: 0px    !important;
      max-width:    0px    !important;
      max-height:   0px    !important;
    }
    

    In this case, the object element that picks up these special style definitions would have a class of hidden. Using the class attribute and the CSS block above, you can simulate the behavior of the hidden plug-in in the embed element:

    <object data="audiplay.aiff" type="audio/x-aiff" class="hiddenObject"></object>
    

    A full-page plug-in is a visible plug-in that is not part of an HTML page. The server looks for the media (MIME) type registered by a plug-in, based on the file extension, and starts sending the file to the browser. Gecko looks up the MIME type and loads the appropriate plug-in if it finds a plug-in registered to that type. This type of plug-in completely fills the web page. Full-page plug-ins are commonly used for document viewers, such as Adobe Acrobat.

    Note: The browser does not display scroll bars automatically for a full-page plug-in. The plug-in must draw its own scroll bars if it requires them.

    The browser user interface remains relatively constant regardless of which type of plug-in is displayed. The part of the application window that does not display plug-in data does not change. The basic operations of the browser, such as navigation, history, and opening files, apply to all pages, regardless of the plug-ins in use.

    Using the object element for plug-in display

    The <object> element is part of the HTML specification for generic inclusion of special media in a web page. It embeds a variety of object types in an HTML page, including plug-ins, Java components, ActiveX controls, applets, and images. object element attributes determine the type of object to embed, the type and location of the object's implementation (code), and the type and implementation of the object's data.

    Plug-ins were originally designed to work with the embed element rather than the object element (see Using the embed Element for Plug-in Display), but the object element itself provides some flexibility here. In particular, the object element allows you to invoke another object if the browser cannot support the object invoked by the element. The embed element, which is also used for plug-ins, does not.

    The object element is also a part of the HTML W3C standard.

    Also, unlike the <applet> element, object can contain other HTML elements including other object elements, nested between its opening and closing tags. So, for example, though Gecko does not support the classid attribute of the object element - which was used for Java classes and ActiveX plug-ins embedded in pages - object elements can be nested to support different plug-in implementations.

    See the Mozilla ActiveX project page in the Plug-in References section below for more information about embedding ActiveX controls in plug-ins or embedding plug-ins in ActiveX applications.

    The following examples demonstrate this use of nested object elements with markup more congenial to Gecko included as children of the parent object element.

    Example 1: Nesting object Elements

    <html>
    <head>
    <title>Example 1: Nesting object Elements</title>
    <style type="text/css">
      .myPlugin {
         width:  470px;
         height: 231px;
      }
    </style>
    </head> 
    <body><p>
    <object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"
            codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=5,0,30,0" 
            class="myPlugin">
     
      <param name="movie" value="foo.swf"/>
      <param name="quality" value="high"/>
      <param name="salign" value="tl"/>
      <param name="menu" value="0"/>
     
           <object data="foo_movie.swf"
                   type="application/x-shockwave-flash"
                   class="myPlugin"/>
     
             <param name="quality" value="high"/>
             <param name="salign" value="tl"/>
             <param name="menu" value="0"/>
     
              <object type="*" class="myPlugin">
                <param name="pluginspage" 
                       value="http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash"/>
              </object>
     
           </object>
    </object>
    </p></body>
    </html>
    

    The outermost object element defines the classid; the first nested object uses the type value application/x-shockwave-flash to load the Adobe Flash plug-in, and the innermost object exposes a download page for users that do not already have the necessary plug-in. This nesting is quite common in the use of object elements, and lets you avoid code forking for different browser.

    Nesting rules for HTML elements

    The rules for descending into nested object and embed elements are as follows:

    • The browser looks at the MIME type of the top element. If it knows how to deal with that MIME type (i.e., by loading a plug-in that's been registered for it), then it does so.
    • If the browser cannot handle the MIME type, it looks in the element for a pointer to a plug-in that can be used to handle that MIME type. The browser downloads the requested plug-in.
    • If the MIME type is unknown and there is no reference to a plug-in that can be used, the browser descends into the child element, where these rules for handling MIME types are repeated.

    The rest of this section is a brief introduction to this HTML element. For more information on the object element and other elements used for plug-in display, see W3C HTML 4.01 specification.

    To embed a variety of object types in an HTML page, use the object element.

    <object
      classid="classFile"
      data="dataLocation"
      codebase="classFileDir"
      type="MIMEtype"
      align="alignment" 
      height="pixHeight" 
      width="pixWidth"
      id="name"
     >
    
    ...
    
    </object>
    

    The first set of object element attributes are URLs.

    • classid is the URL of the specific object implementation. This attribute is similar to the code attribute of the applet element. Though Gecko does not support this object attribute, you can nest object elements with different attributes to use the object element for embedding plug-ins on any browser platform (see the example above).
    • data represents the URL of the object's data; this is equivalent to the src attribute of embed.
    • codebase represents the URL of the plug-in; this is the same as the codebase attribute of the applet element. For plug-ins, codebase is the same as pluginspace.
    • type represents the MIME type of the plug-in; this is the same as the type attribute of embed.
    • height, width, align are basic img/embed/applet attributes supported by object. height and width are required for object elements that resolve to embed elements.
    • Use the id attribute, which specifies the name of the plug-in, if the plug-in is communicating with JavaScript. This is equivalent to the name attribute of applet and embed. It must be unique.

    Using the appropriate attributes

    It's up to you to provide enough attributes and to make sure that they do not conflict; for example, the values of width and height may be wrong for the plug-in. Otherwise, the plug-in cannot be embedded.

    Gecko interprets the attributes as follows: When the browser encounters an object element, it goes through the element attributes, ignoring or parsing as appropriate. It analyzes the attributes to determine the object type, then determines whether the browser can handle the type.

    • If the browser can handle the type-that is, if a plug-in exists for that type-then all elements and attributes up to the closing </object> element, except param elements and other object elements, are filtered.
    • If the browser cannot handle the type, or cannot determine the type, it cannot embed the object. Subsequent HTML is parsed as normal.

    Using the embed element for plug-in display

    A plug-in runs in an HTML page in a browser window. The HTML author uses the HTML <embed> element to invoke the plug-in and control its display. Though the object element is the preferred way to invoke plug-ins (see Using the object Element for Plug-in Display), the embed element can be used for backward compatibility with Netscape 4.x browsers, and in cases where you specifically want to prompt the user to install a plug-in, because the default plug-in is only automatically invoked when you use the embed element.

    Gecko loads an embedded plug-in when the user displays an HTML page that contains an embedded object whose MIME type is registered by a plug-in. Plug-ins are embedded in much the same way as GIF or JPEG images are, except that a plug-in can be live and respond to user events, such as mouse clicks.

    The embed element has the following syntax and attributes:

    <embed 
      src="location"
      type="mimetype"
      pluginspage="instrUrl"
      pluginurl="pluginUrl"
      align="left"|"right"|"top"|"bottom"
      border="borderWidth" 
      frameborder="no"
      height="height" 
      width="width"
      units="units"
      hidden="true|false"
      hspace="horizMargin" 
      vspace="vertMargin" 
      name="pluginName"
      palette="foreground"|"background"
     >
     
    ...
     
    </embed>
    

    You must include either the src attribute or the type attribute in an embed element. If you do not, then there is no way of determing the media type, and so no plug-in loads.

    The src attribute is the URL of the file to run. The type attribute specifies the MIME type of the plug-in needed to run the file. Navigator uses either the value of the type attribute or the suffix of the filename given as the source to determine which plug-in to use.

    Use type to specify the media type or MIME type necessary to display the plug-in. It is good practice to include the MIME type in all the plug-in HTML elements. You can use type for a plug-in that requires no data, for example, a plug-in that draws an analog clock or fetches all of its data dynamically. For a visible plug-in, you must include width and height if you use type; no default value is used.

    The pluginurl attribute is the URL of the plug-in or of the XPI in which the plug-in is stored (see Installing Plug-ins for more information on the XPI file format).

    The embed element has a number of attributes that determine the appearance and size of the plug-in instance, including these:

    • The border and frameborder attributes specify the size of a border for the plug-in or draw a borderless plug-in
    • height, width, and units determine the size of the plug-in in the HTML page. If the plug-in is not hidden, the height and width attributes are required.
    • hspace and vspace create a margin of the specified width, in pixels, around the plug-in.
    • align specifies the alignment for the plug-in relative to the web page.

    Use the hidden attribute if you do not want the plug-in to be visible. In this case, you do not need the attributes that describe plug-in appearance. In fact, hidden overrides those attributes if they are present.

    Use the name attribute, which specifies the name of the plug-in or plug-in instance, if the plug-in is communicating with JavaScript.

    For example, this embed element loads a picture with the imaginary data type dgs.

    <embed src="mypic.dgs" width="320" height="200" border="25" align="right">
    

    Gecko interprets the attributes as follows:

    • src: Load the data file and determine the MIME type of the data.
    • width and height: Set the area of the page handled by the plug-in to 320 by 200 pixels. In general, use CSS to control the size and location of elements within an HTML page.
    • border: Draw a border 25 pixels wide around the plug-in.
    • align: Align the plug-in at the right side of the web page.

    The following example shows an embed element nested within an object element, which latter is necessary for browsers that do not support the embed element.

    Example 2: embed within object

    <object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" 
       codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=5,0,30,0" 
       width="749" height="68">
    
     <param name="movie" value="foo.swf">
     <param name="quality" value="high">
     <param name="bgcolor" value="#EEEEEE">
     <param name="salign" value="tl">
     <param name="menu" value="0">
     
     <embed src="foo.swf" 
       quality="high" pluginspage="http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash" 
       type="application/x-shockwave-flash" 
       width="749" 
       height="68" 
       bgcolor="#EEEEEE" 
       salign="tl" 
       menu="0">
     
     </embed>
     
    </object>
    

    Using custom embed attributes

    In addition to these standard attributes, you can create private, plug-in-specific attributes and use them in the embed attribute to pass extra information between the HTML page and the plug-in code. The browser ignores these nonstandard attributes when parsing the HTML, but it passes all attributes to the plug-in, allowing the plug-in to examine the list for any private attributes that could modify its behavior.

    For example, a plug-in that displays video could have private attributes that determine whether to start the plug-in automatically or loop the video automatically on playback, as in the following embed element:

    <embed src="myavi.avi" width="100" height="125" autostart="true" loop="true">
    


    With this embed element, Gecko passes the values to the plug-in, using the arg parameters of the NPP_New call that creates the plug-in instance.

    argc = 5
    argn = {"src", "width", "height", "autostart", "loop"}
    argv = {"movie.avi", "100", "125", "true", "true"}
    

    Gecko interprets the attributes as follows:

    • src: Load the data file and determine the MIME type of the data.
    • width and height: Set the area of the page handled by the plug-in to 100 by 125 pixels.
    • autostart and loop: Ignore these private attributes and pass them along to the plug-in with the rest of the attributes.

    The plug-in must scan its list of attributes to determine whether it should automatically start the video and loop it on playback. Note that with an object element, param values are also sent in this array after the attributes, separated by a param entry.

    Plug-in references

    文档标签和贡献者

    此页面的贡献者有: ziyunfei, sa_water, ericchan1336
    最后编辑者: ziyunfei,