Intent to Implement: <webview>

[Kan-Ru Chen (陳侃如)]

Summary:
Currently we have <iframe mozbrowser> which has a bunch additional
functionality than simple <iframe> and is a top level browsing context
by itself. Having <webview> avoids overloading <iframe> and provides
clarity. We also think this is the right direction towards the
standardization of the browser-element.

For the story of <iframe mozbrowser> see
https://hacks.mozilla.org/2014/08/building-the-firefox-browser-for-firefox-os/

Bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=738172

Link to standard:
Currently no formal standard. Ben Francis has created a draft which
largely resembles the current mozbrowser API. Google and Microsoft both
have their <webview> implementation similar to this proposal.

http://benfrancis.github.io/webview/
https://developer.mozilla.org/en-US/docs/Web/API/Using_the_Browser_API
https://developer.chrome.com/apps/tags/webview
http://msdn.microsoft.com/en-gb/library/windows/apps/dn301831.aspx

Platform coverage:
Initially on Firefox OS

Estimated or target release:
Firefox OS 2.4

Preference behind which this will be implemented:
It will be behind a pref dom.enable_webview. The html5 parser should be
taught to treat the tag as HTMLUnknownElement when preffed off.

[Jonas Sicking]

This will only be exposed to privileged and certified apps, right?
Other content that does createElement("webview") will simply get a
HTMLUnknownElement, right?

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Daniel Veditz]

On 10/13/2014 9:15 AM, Jonas Sicking wrote:
> This will only be exposed to privileged and certified apps, right?
> Other content that does createElement("webview") will simply get a
> HTMLUnknownElement, right?

What does an unprivileged app get if it tries to use <iframe
mozbrowser>? Probably not an HTMLUnknownElement. Why not treat it as a
synonym for an unprivleged iframe in that case?

(OK, so I sort of answered my own question: because then people might
accidentally start using it as a synonym for iframe in the unprivileged
case and that broken use might leak into the desktop context.)

-Dan Veditz

[Robert O'Callahan]

On Mon, Oct 13, 2014 at 2:54 AM, Kan-Ru Chen (陳侃如) <kc...@mozilla.com>
wrote:

> Link to standard:
> Currently no formal standard. Ben Francis has created a draft which
> largely resembles the current mozbrowser API. Google and Microsoft both
> have their <webview> implementation similar to this proposal.
>
> http://benfrancis.github.io/webview/
> https://developer.mozilla.org/en-US/docs/Web/API/Using_the_Browser_API
> https://developer.chrome.com/apps/tags/webview
> http://msdn.microsoft.com/en-gb/library/windows/apps/dn301831.aspx
>

Thanks, I didn't know MS and Chrome both have this. This makes a lot of
sense!

Rob
--
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.

[Jonas Sicking]

On Mon, Oct 13, 2014 at 11:00 AM, Daniel Veditz <dve...@mozilla.com> wrote:
> On 10/13/2014 9:15 AM, Jonas Sicking wrote:
>> This will only be exposed to privileged and certified apps, right?
>> Other content that does createElement("webview") will simply get a
>> HTMLUnknownElement, right?
>
> What does an unprivileged app get if it tries to use <iframe
> mozbrowser>? Probably not an HTMLUnknownElement. Why not treat it as a
> synonym for an unprivleged iframe in that case?

Because that means that we're adding a new <webview> element to the
wider web platform that we'd have to support for ever and ever.

Also keep in mind that you aren't likely to get a "useful" fallback if
you simply treat <webview> as an <iframe>. So we're not really doing
anyone any favors anyway.

By leaving the wider web platform unchanged, we'll have much more
ability to modify this feature in the future in order to align with
other implementations or a future standard.

> (OK, so I sort of answered my own question: because then people might
> accidentally start using it as a synonym for iframe in the unprivileged
> case and that broken use might leak into the desktop context.)

Exactly.

/ Jonas

[Kan-Ru Chen (陳侃如)]

Jonas Sicking <jo...@sicking.cc> writes:

> This will only be exposed to privileged and certified apps, right?
> Other content that does createElement("webview") will simply get a
> HTMLUnknownElement, right?

Correct.

Kanru

[Jonas Sicking]

Cool, then this sounds great to me!

Where is this API discussed? I'd like to take the opportunity to fix
some of the bugs that we have in <iframe mozbrowser>.

/ Jonas

[Kan-Ru Chen (陳侃如)]

Cool. Please post your ideas to dev-webapi with [webview] prefix in
subject.

Kanru

[Ehsan Akhgari]

On 2014-10-13, 10:35 PM, Kan-Ru Chen (陳侃如) wrote:
> Jonas Sicking <jo...@sicking.cc> writes:
>
>> On Mon, Oct 13, 2014 at 4:36 PM, Kan-Ru Chen (陳侃如) <kc...@mozilla.com> wrote:
>>> Jonas Sicking <jo...@sicking.cc> writes:
>>>
>>>> This will only be exposed to privileged and certified apps, right?
>>>> Other content that does createElement("webview") will simply get a
>>>> HTMLUnknownElement, right?
>>>
>>> Correct.
>>
>> Cool, then this sounds great to me!
>>
>> Where is this API discussed? I'd like to take the opportunity to fix
>> some of the bugs that we have in <iframe mozbrowser>.
>
> Cool. Please post your ideas to dev-webapi with [webview] prefix in
> subject.

Well, <http://benfrancis.github.io/webview/> is mostly empty right now,
so that may be hard to do. :-) Should we discuss the API more before
we move towards implementing it?

[Kan-Ru Chen (陳侃如)]

Let's get started and send proposals :)

Kanru