MozillaWiki

WebAPI/WidgetAPI: Difference between revisions

Page Discussion

WebAPI/WidgetAPI (view source)

Revision as of 03:06, 17 July 2015

4,260 bytes added ,  17 July 2015
Prevent Pages to Be Embedded {{bug|1043110}}
(Prevent Pages to Be Embedded {{bug|1043110}})
 
(45 intermediate revisions by 6 users not shown)
Line 1: Line 1:
== Goals ==
== Goals ==
The widget API allows privileged APPs have ability to embed APPs in their own iframe, i.e. homescreen, lockscreen ....etc.
The widget API allows privileged application have ability to embed other applications in their own iframe, e.g. homescreen, lockscreen ....etc.


==Use case==
== Use case ==
==Proposal==
== Proposal ==
=== embed-widgets {{bug|1005818}} ===
=== extend manifest.webapp ===
In order to expose to privileged APPs and consider security issue.<br />
An application exposes its widget view via declaring details of widget in mainfest.
* "embed-widgets" is a new permission for "mozapp" attribute, it comes from [https://developer.mozilla.org/en-US/Apps/Build/App_permissions#embed-apps 'embed-apps'] but is more restricted. Please refer to [https://wiki.mozilla.org/WebAPI/WidgetAPI#Browser_API next section].
* Set manifest entry in "widget" attribute. 
  <iframe mozapp="manifesturl" widget="mywidget1">
 
===extend manifest.webapp===
Declare details of widget in mainfest.


   {
   {
Line 18: Line 12:
     widgets: {
     widgets: {
       "mywidget1": {
       "mywidget1": {
         href: "widget.html"
         "name": "MyApp2000 Widget",
         positions: ["homescreen", "lockscreen"]
        "launch_path": "/widget.html",
         description: "This is my cool widget"
         "description": "This is my cool widget",
        "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: [
      "/widget.html",
      "/widget_en-US.html",
      "/news_reader_settings.html",
      "/some_other_page.html"
    ]
   }
   }


==== 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}} ===
In order to expose to privileged APPs and consider security issue.
* "embed-widgets" is a new permission for "mozwidget" attribute, it is similar to [https://developer.mozilla.org/en-US/Apps/Build/App_permissions#embed-apps 'embed-apps'] but is more restricted. Please refer to [https://wiki.mozilla.org/WebAPI/WidgetAPI#Browser_API next section].
* Set manifest entry in "widget" attribute. 
  <iframe mozbrowser=“true" mozwidget="manifestURL" src=“widget.html” remote=“true”>


=== permission requirements ===
=== permission requirements ===
Line 32: Line 54:
*browser-api (combine with embed-widget would be downgrade )
*browser-api (combine with embed-widget would be downgrade )


=== Restriction ===
==== Restriction ====
*Disallow SRC attribute.
*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:
   <iframe mozbrowser=“true" mozapp=“manifestURL” remote=“true” src=“appURL”>
   <iframe mozbrowser=“true" mozapp=“manifestURL” remote=“true” src=“appURL”>


*Widget:
*Widget:
**Disallow “src" attribute.
   <iframe mozbrowser=“true" mozwidget=“manifestURL” remote=“true” src=”widgetURL”>  
  //Q: Can we set remote is true by default?
   <iframe mozbrowser=“true" mozapp=“manifestURL" widget=“widgetEntry” remote=“true”>  


*Open Bookmark:
*Open Bookmark:
   //browser (full-set)
   //browser (full-set)
   <iframe mozbrowser src="" remote="true">
   <iframe mozbrowser=“true" remote="true" src="http://example.com">
 
=== Prevent Pages to Be Embedded {{bug|1043110}} ===
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,
*for existing app page: show NS_ERROR_MALFORMED_URI
*for missing app page: show NS_ERROR_MALFORMED_URI
*for external web page: show NS_ERROR_MALFORMED_URI
 
=== Other Notes ===
==== 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.


==Issues under discussion==
==Limited Browser API==
===[https://developer.mozilla.org/zh-TW/docs/WebAPI/Browser#.E5.AD.98.E5.8F.96_%28Navigation%29_.E5.87.BD.E5.BC.8F Browser API]===
===[https://developer.mozilla.org/zh-TW/docs/WebAPI/Browser#.E5.AD.98.E5.8F.96_%28Navigation%29_.E5.87.BD.E5.BC.8F Browser API]===
Need to clarify which methods/Events are safe or unsafe.
Need to clarify which methods/Events are safe or unsafe.
Line 63: Line 94:


*Events
*Events
**mozbrowserasyncscroll
**mozbrowserclose
**mozbrowserclose
**mozbrowsererror
**mozbrowsererror
**mozbrowserloadend
**mozbrowserloadend
**mozbrowserloadstart
**mozbrowserloadstart
**mozbrowserfirstpaint
**mozbrowserdocumentfirstpaint


==== Security sensitive ====
==== Security sensitive ====
Line 86: 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 97: Line 131:
*Performance methods
*Performance methods
**<strike>purgeHistory()</strike>
**<strike>purgeHistory()</strike>
*Events
**<strike>mozbrowserasyncscroll</strike>
**<strike>mozbrowserresize</strike>
**<strike>mozbrowseractivitydone</strike>
**<strike>mozbrowserscroll</strike>
==Q&A==
* Why we need an app to explicitly expose its widget view? Is there any use case that an app doesn't want to be opened as a widget?
** The app thinks its function can't be performed in widget mode, like lockscreen app or camera app.
** Just doesn't want itself to be embeded by other apps for various concerns, like Facebook app or bank apps.
* Is it possible to navigate to an external link within a widget?
** It should be fine to navigate an external link within a widget because window.location is changed by widget itself under its window context, not caused by the widget embedder.
** A widget is also an iframe. It follows "X-Frame-Options" restrictions. If a web page declare X-Frame-Options, the widget cannot shows that page.


==Experimental Note==
* May a widget request to enlarge itself to full screen as its app mode?
** No, we don't have a better idea for this case now. Issues like how to force homescreen app to deal with the the resize event requested by widget, how to update mozbrowser iframe attributes to indicate the frame is in app mode...


* What will happen when a pure iframe (without mozbrowser/mozapp/remote) calls "window.top.location = window.location" within an app?
* 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?
** It works. The embedder window will be overwritten.
** 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.


* Can a pure iframe steal the permissions from its embedder?
* What happens when embedder removes the mozwidget attribute of existing iframe?
** No. Even the window.top is overwritten.
** Nothing. We still follows the widget API rules to manage the iframe, the limited APIs and the same permissions.


* What will happen when an iframe has mozapp but doesn't have mozbrowser?
* What happens when embedder uses mozapp originally and swap it as mozwidget?
** "remote=true" malfunction. So, no permission can be obtained.
** Nothing. We still follows the mozapp API rules to manage the iframe, the full-set browser API and the same permissions.


* Does the visibility state of an OOP'ed iframe correspond to its parent?
* What happens when embedder removes the mozwidget and changes the src of an existing iframe?
** Yes.
** 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==
* <del>{{bug|1005818}}</del> A new 'embed-widgets' permission exposing to privileged apps for solving widget case.
** Part 1: Load a widget as an app if the |src| is in the |widgetPages|
** Part 2: 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/982013...1085275"