MozillaWiki

WebAPI/WidgetAPI: Difference between revisions

Page Discussion

WebAPI/WidgetAPI (view source)

Revision as of 03:06, 17 July 2015

1,539 bytes added ,  17 July 2015
Prevent Pages to Be Embedded {{bug|1043110}}
(Prevent Pages to Be Embedded {{bug|1043110}})
 
(20 intermediate revisions by 3 users not shown)
Line 13: Line 13:
       "mywidget1": {
       "mywidget1": {
         "name": "MyApp2000 Widget",
         "name": "MyApp2000 Widget",
         "href": "/widget.html",
         "launch_path": "/widget.html",
         "description": "This is my cool widget",
         "description": "This is my cool widget",
         "screenshot": "foo.jpg"
         "preview_image": "foo.jpg",
        "locales": {
          "en-US": {
            "launch_path": "/widget_en-US.html",
            "name":"MyApp2000 Widget",
            "description":"This is my cool widget",
            "preview_image": "foo_en-US.jpg"
          }
        }
       },
       },
       "myotherwidget": { ... }
       "myotherwidget": { ... }
     }
     },
     widgetPages: [
     widgetPages: [
       "/widget.html",
       "/widget.html",
      "/widget_en-US.html",
       "/news_reader_settings.html",
       "/news_reader_settings.html",
       "/some_other_page.html"
       "/some_other_page.html"
     ]
     ]
    "locales": {
      "en-US": {
        "name" : "MyApp2000",
        "discription":"Cool App",
        "widgets": {
          "mywidget1": {
            "name":"MyApp2000 Widget",
            "description":"This is my cool widget",
            "screenshot": "foo_en-US.jpg"
          },
          "myotherwidget": { ... }
        }
      }
    }
   }
   }
==== Manifest with Entry Points ====
For some app with entry_points declared, we still use "widgets" field at the top level of manifest to decouple the relationship between entry points and widgets.
==== Localization of Widget Info ====
Similar to app's localization, the localization of widget MUST be embedded in its declaration.


=== embed-widgets {{bug|1005818}} ===
=== embed-widgets {{bug|1005818}} ===
Line 53: Line 55:


==== Restriction ====
==== Restriction ====
*Limite SRC value in widgetPages list.
*iframe SRC MUST BE one of widgetPages list.
*Disallow parts of security sensitive browser API
*Disallow parts of security sensitive browser API
*Ignore mozLockOrientation/mozUnlockOrientation
*Ignore mozLockOrientation/mozUnlockOrientation
==== examples ====
==== examples ====
*APP:
*APP:
Line 67: Line 70:
   <iframe mozbrowser=“true" remote="true" src="http://example.com">
   <iframe mozbrowser=“true" remote="true" src="http://example.com">


=== Prevent Pages to Be Embedded ===
=== Prevent Pages to Be Embedded {{bug|1043110}} ===
==== Packaged App ====
Widgets' pages MUST be listed in "widgetPages" field which is the white list of widget pages. All pages in this list can be accessed through widget iframe. Others are shown as error pages, including other app pages and external pages. If the widget frame's src points to a page which is NOT listed in widgetPages,
An app can use "widgetPages" to list the white list of widget pages. All pages in this list can be accessed through widget iframe. Others are shown as blank page.
*for existing app page: show NS_ERROR_MALFORMED_URI
*If a widget navigates to pages which are not listed in widgetPages, the widget iframe shows blank on it.
*for missing app page: show NS_ERROR_MALFORMED_URI
*If a widget navigates to another domain, the widget iframe cannot use any APIs which requires permissions.
*for external web page: show NS_ERROR_MALFORMED_URI
 
==== Web Pages ====
A web page can declare itself to not be embedded in widget iframe by "X-Frame-Options", like normal web page. For more options of X-Frame-Options can be found at: https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options


=== Localization of Widget Info ===
=== Other Notes ===
Similar to app's localization, the localization of widget info MUST be embedded in "widgets" of "locales" properties. And they are referenced to each other with widget id, like mywidget1 or myotherwidget.
==== The Timing of Granting Permissions and Limiting Browser API ====
All permissions and the browser APIs are granted at iframe attached to DOM tree. Once done, Gecko creates/finds a process for this widget and associates them. The permissions and APIs are defined at that time. There is nothing happened when embedder tries to remove the mozwidget attribute or swap mozwidget to mozapp after that. If embedder removes mozwidget and changes the src, iframe still follows the widgetPages rule to check it.


==Limited Browser API==
==Limited Browser API==
Line 97: Line 98:
**mozbrowserloadend
**mozbrowserloadend
**mozbrowserloadstart
**mozbrowserloadstart
**mozbrowserfirstpaint
**mozbrowserdocumentfirstpaint


==== Security sensitive ====
==== Security sensitive ====
Line 115: Line 118:
**mozbrowsertitlechange - discloses title, privacy issue.
**mozbrowsertitlechange - discloses title, privacy issue.
**mozbrowseropensearch - I assume this discloses the link value, maybe a privacy issue?
**mozbrowseropensearch - I assume this discloses the link value, maybe a privacy issue?
**mozbrowsermanifestchange
**mozbrowsermetachange


=== no use case ===
=== no use case ===
Line 128: Line 133:
*Events
*Events
**<strike>mozbrowserasyncscroll</strike>
**<strike>mozbrowserasyncscroll</strike>
**<strike>mozbrowserresize</strike>
**<strike>mozbrowseractivitydone</strike>
**<strike>mozbrowserscroll</strike>


==Q&A==
==Q&A==
Line 143: Line 151:
* Some apps want to app.launch() its app mode while user click its widget, but some want to be enlarged.  Is there a way to specify?
* Some apps want to app.launch() its app mode while user click its widget, but some want to be enlarged.  Is there a way to specify?
** We may introduce an attribute in manifest which tells widget embedder how to process the enlarging behavior. But we have to discuss it with Web API team.
** We may introduce an attribute in manifest which tells widget embedder how to process the enlarging behavior. But we have to discuss it with Web API team.
* What happens when embedder removes the mozwidget attribute of existing iframe?
** Nothing. We still follows the widget API rules to manage the iframe, the limited APIs and the same permissions.
* What happens when embedder uses mozapp originally and swap it as mozwidget?
** Nothing. We still follows the mozapp API rules to manage the iframe, the full-set browser API and the same permissions.
* What happens when embedder removes the mozwidget and changes the src of an existing iframe?
** Nothing. We still follows the widget API rules. If the src is in widgetPages, nothing happens. If the src is not in widgetPages, an error is emitted NS_ERROR_DOM_INVALID_ACCESS_ERR or NS_ERROR_FILE_NOT_FOUND.


==Bugs==
==Bugs==
* {{bug|1005818}} A new 'embed-widgets' permission exposing to privileged apps for solving widget case.
* <del>{{bug|1005818}}</del> A new 'embed-widgets' permission exposing to privileged apps for solving widget case.
** Part1: Add permission "embed-widgets" and HTMLIFrameElement attribute "mozWidget"
** Part 1: Load a widget as an app if the |src| is in the |widgetPages|
** Part2: Implementation of checking if a window is able to embed a specific widget.
** Part 2: Only limited browser API are available to a widget
** Part3: Enable to embed a widget if preconditions hold
 
** Part4: Only limited browser API are available to a widget
* {{bug|1043110}}  an appropriate way to prevent forbidden pages to be embedded in a widget iframe
* {{bug|1052328}}  Let privileged apps be able to launch a widget via APP protocol URIs
* {{bug|1052334}}  create a function to retrieve preview image of widget
* {{bug|1053724}}  Prevent Widget Frame to Listen/Handle System Message
 
[[Category:Web APIs]]
Junior Hsu
Confirmed users
29

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/994893...1085275"