Closed
Bug 738172
Opened 13 years ago
Closed 2 years ago
Switch from <iframe mozbrowser> to <webview> (or whatever)
Categories
(Core :: DOM: Core & HTML, defect, P5)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: mounir, Unassigned)
References
()
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>.
Updated•13 years ago
|
Blocks: browser-api
Updated•12 years ago
|
Keywords: dev-doc-needed
Comment 1•12 years ago
|
||
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.
Comment 2•12 years ago
|
||
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?
Reporter | ||
Comment 3•12 years ago
|
||
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.
Comment 4•12 years ago
|
||
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.
Comment 5•12 years ago
|
||
Mounir confirmed it doesn't block V1, removing from dependency tree.
No longer blocks: browser-api
Updated•12 years ago
|
Depends on: browser-api
Comment 6•12 years ago
|
||
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.
Comment 7•12 years ago
|
||
FWIW, Chrome Apps ended up shipping this as <webview>.
Comment 8•12 years ago
|
||
Thanks Ojan, good to know! Is there any documentation of this HTML element and its associated API for comparison?
Comment 9•12 years ago
|
||
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.
Updated•12 years ago
|
Depends on: b2g-v-next
Updated•11 years ago
|
Assignee: nobody → kchen
Summary: Switch from <iframe mozbrowser> to <browser> → Switch from <iframe mozbrowser> to <webview> (or whatever)
Updated•11 years ago
|
Comment 10•11 years ago
|
||
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">
Updated•10 years ago
|
Blocks: browser-api, b2g-v-next
No longer depends on: browser-api, b2g-v-next
Comment 11•10 years ago
|
||
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="">.
Comment 12•10 years ago
|
||
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.
Updated•6 years ago
|
Priority: -- → P5
Updated•2 years ago
|
Severity: normal → S3
Comment 13•2 years ago
|
||
The bug assignee is inactive on Bugzilla, so the assignee is being reset.
Assignee: kanru → nobody
Comment 14•2 years ago
|
||
mozbrowser will be gone, hopefully soon, bug 1574886 and others.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•