Open Bug 738172 Opened 8 years ago Updated Last year

Switch from <iframe mozbrowser> to <webview> (or whatever)

Categories

(Core :: DOM: Core & HTML, defect, P5)

defect

Tracking

()

People

(Reporter: mounir, Assigned: kanru)

References

(Blocks 1 open bug, )

Details

(Keywords: dev-doc-needed)

After a discussion on dev-webapi, Justin and I came into an agreement that we should move from <iframe mozbrowser> to <browser> for various reasons like semantic and ease of standardization.

The element name might change later if we want to have something generic that would include applications. Unless we end up adding <app>.
How about <webview>? <browser> seems far too general. To me it implies having an address bar, windows and possibly tabs, bookmarks, etc. 

FWIW, Chrome Apps is currently going with <browser> for consistency with Gecko. I've talked informally to the Chrome Apps folk and they are fine with <webview>.

Perhaps I should bring this up in the sysapps WG. It's not clear to me if that group is quite ready for these detailed sorts of discussions.
I'd be fine with <webview>, but Mounir is the one who feels strongly about this, so let's wait a few days until he's back from vacation?
I'm fine with <webviwe> too. I think <browser> is quite confusing too because things in <browser> are actually tabs, and the browser is the frame containing those. <webview> will reduce quite significantly that confusion.
Is this required for V1? If so, please nominate for blocking. Otherwise, can you remove from the BrowserAPI dependency tree? that's what we're using to track V1-required work in these metabugs.
Mounir confirmed it doesn't block V1, removing from dependency tree.
No longer blocks: browser-api
Depends on: browser-api
If we remove all non-v1 blockers from the browser-api metabug, we will lose bugs, which is sad.  We discussed this on IRC and (provisionally) decided to go back to how things were.
FWIW, Chrome Apps ended up shipping this as <webview>.
Thanks Ojan, good to know! Is there any documentation of this HTML element and its associated API for comparison?
Unfortunately, we don't have anything at the moment. We're working on making our design process more public, but not quite there yet. :(

In any case, if you want to chat about details fsamuel@chromium.org is the one to talk to.
Assignee: nobody → kchen
Summary: Switch from <iframe mozbrowser> to <browser> → Switch from <iframe mozbrowser> to <webview> (or whatever)
Is this work in anyone's backlog yet? The mozbrowser iframe attribute is getting more widely used in third party (privileged) apps and there's talk of opening up the mozapp attribute to privileged apps as well on dev-webapi.

I'd also like to propose that the mozapp attribute of iframes should become a manifest attribute of webviews which points to an Open Web App manifest or ultimately a W3C Manifest, to limit the webview to the scope of a particular app, e.g.

<webview manifest="http://foo.com/manifest.json">
No longer depends on: browser-api, b2g-v-next
Blocks: 1044736
Note the description of "scope" in the Web Manifest Explainer on HTML5 Doctor http://html5doctor.com/web-manifest-specification/ . A "scope" property is expected to be added to a forthcoming editor's draft of the W3C Web Manifest specification http://w3c.github.io/manifest which limits an app to a particular URL scope.

I would again like to propose that <webview> have a "manifest" property (e.g. <webview manifest="http://foo.com/manifest.json">) which limits the webview to a particular URL scope, defined in the manifest.

So <iframe mozbrowser> could become <webview> and <iframe mozbrowser mozapp=""> could become <webview manifest="">.
Also note that a while ago I started a proposal for a <webview> specification based on Chrome and Gecko implementations http://benfrancis.github.io/webview/

Comments welcome.
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.