Browser API proposal

[Justin Lebar]

I'd like to get feedback on the following proposed browser API.

I expect to flush out details of this API as we implement it; what I'd
like here is feedback on the high-level idea.

For our purposes, a "browser" is a webpage which contains an <iframe
mozbrowser>. We call the iframe the "content iframe". The window in
the iframe is the browser's "content window", while the window which
contains the iframe is the "browser window".

The way this currently works in b2g is, when Gecko sees an <iframe
mozbrowser>, it funnels certain events up out of the content window
and onto the content iframe. The browser window can then listen to
location change, load start, and load finished on the iframe and
update the UI accordingly.

The problem with this approach is that the necessary API is large. If
the browser window is basically Firefox's browser.js, then the API
specifies every point at which browser.js listens to or looks at
content. Particularly tricky are things like window.alert() and
window.open() -- we want the browser window to handle this. See the
wiki [1] for a list of just some of the APIs we'd have to write.

My proposal is to simplify the Gecko API and push as much complexity
as feasible into the browser window itself. (This mirrors a general
trend in our platform.)

The browser window would have one API call: Pass in a script (as a
string) which is run in the content window whenever we load a new
document there. The script is run before any script is run in the
content window.

This script has an object which allows two-way communication with the
browser window. We allow asynchronous communication in both
directions, and we allow content to make synchronous calls up to the
browser (this is important for alert()).

The script is expected to register listeners (e.g. window.hashchange,
window.popstate) and to wrap JS methods (e.g. window.alert,
window.open). Thus we can handle most of the necessary parts of the
browser API by observing the page itself.

This would not get us 100% of the way to a working browser. We don't
have APIs for content to read some things (e.g. whether the throbber
should be spinning, or whether it's a secure page), and content can't
run some functions, such as the stop button. We can decide whether to
expose this functionality to the content window, or to expose it on
the content iframe.

As usual, history is a huge pain. We can do the back / forward
buttons using what we have now, but if the browser wanted to have a
history drop-down list which matched the back/forward buttons, we'd
have to add a new API.

Although it's not a complete solution, I think this API is likely
easier to implement in Gecko than the alternative. It certainly gives
browsers more freedom. I'm hopeful it's also more robust to additions
to the platform than the alternative, which makes it more likely to
become a standard.

I'm curious to hear what you think.

-Justin

[1] https://wiki.mozilla.org/WebAPI/EmbeddedBrowserAPI

[Rick Waldron]

This is definitely exciting. If I understand correctly, this would be the
web's version of the iOS UIWebView and Android WebView?

Rick

> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi
>

[Chris Jones]

----- Original Message -----
> From: "Justin Lebar" <justin...@gmail.com>
> To: dev-w...@lists.mozilla.org
> Cc: "Ben Francis" <b...@krellian.com>
> Sent: Wednesday, March 7, 2012 9:01:39 AM
> Subject: Browser API proposal
>
> The problem with this approach is that the necessary API is large.
> If
> the browser window is basically Firefox's browser.js, then the API
> specifies every point at which browser.js listens to or looks at
> content. Particularly tricky are things like window.alert() and
> window.open() -- we want the browser window to handle this. See the
> wiki [1] for a list of just some of the APIs we'd have to write.
>

These are general problems that we'll solve generally.

> The browser window would have one API call: Pass in a script (as a
> string) which is run in the content window whenever we load a new
> document there. The script is run before any script is run in the
> content window.
>

We discussed this in person. I agree that this API will be needed eventually, but I want to hold on it as long as possible. I want this to be a nuclear option, an extremely sensitive privilege, since reviewing the behavior of a browser app that requests this is going to be an amazingly hard problem.

Is there some use case that's come up recently for which this "frame script" API is the only viable solution?

Cheers,
Chris

[Justin Lebar]

> We discussed this in person.

We did, but all I remember is that you were opposed to it, not why. :)

> I agree that this API will be needed eventually, but I want to hold on it as long as possible. I want this to be a nuclear
> option, an extremely sensitive privilege, since reviewing the behavior of a browser app that requests this is going to be
> an amazingly hard problem.

I don't understand why it should be any harder to review a browser app
which requests this privilege than to review Gecko or chrome JS which
implements this API.

Would you be happy if there was a chrome JS file which we inserted
into every mozbrowser content window, which forwarded information back
up to the browser window? I bet we could do this just as easily, if
not more easily, than my original proposal.

Using chrome JS to send events up to the browser app seems suboptimal
to me, because this chrome JS will be tightly coupled with the browser
app. I'd rather have the whole browser app be self-contained. But
this would still be a nicer solution, imo, than writing everything
into Gecko.

-Justin

[Chris Jones]

----- Original Message -----
> From: "Justin Lebar" <justin...@gmail.com>

> To: "Chris Jones" <cjo...@mozilla.com>
> Cc: "Ben Francis" <b...@krellian.com>, dev-w...@lists.mozilla.org
> Sent: Wednesday, March 7, 2012 4:24:26 PM
> Subject: Re: Browser API proposal
>
> > I agree that this API will be needed eventually, but I want to hold
> > on it as long as possible. I want this to be a nuclear
> > option, an extremely sensitive privilege, since reviewing the
> > behavior of a browser app that requests this is going to be
> > an amazingly hard problem.
>
> I don't understand why it should be any harder to review a browser
> app
> which requests this privilege than to review Gecko or chrome JS which
> implements this API.
>

A browser app is 100% new and comes from an untrusted source, in general. Gecko/chrome JS usually comes from engineers with an existing reputation, and patches there build on a large body of existing knowledge and code. Even then we get those reviews wrong and allow privacy/security bugs to slip through.

If Jane Doe from Grytviken, Antarctica submitted a patch out of the blue to completely rewrite browser/base/content/browser.js, how long do you think it would take to review that patch?

> Would you be happy if there was a chrome JS file which we inserted
> into every mozbrowser content window, which forwarded information
> back
> up to the browser window? I bet we could do this just as easily, if
> not more easily, than my original proposal.
>

Oh, I thought that's what we were doing already. Yes, I'm in favor of that because (IIUC) it's exposing a much smaller API surface area to content. (Which presumably is consuming the information in the browser app context?)

> Using chrome JS to send events up to the browser app seems suboptimal
> to me, because this chrome JS will be tightly coupled with the
> browser
> app. I'd rather have the whole browser app be self-contained. But
> this would still be a nicer solution, imo, than writing everything
> into Gecko.
>

OK, maybe I misunderstand your proposal.

Like I said, TBH I think we'll eventually need to allow browser apps to inject arbitrary JS into content. But I don't want to do that until a use case arises for which we have no other viable option. If you know of such a use case already, then OK.

Cheers,
Chris

[Justin Lebar]

>> > I agree that this API will be needed eventually, but I want to hold
>> > on it as long as possible.  I want this to be a nuclear
>> > option, an extremely sensitive privilege, since reviewing the
>> > behavior of a browser app that requests this is going to be
>> > an amazingly hard problem.
>>
>> I don't understand why it should be any harder to review a browser
>> app
>> which requests this privilege than to review Gecko or chrome JS which
>> implements this API.
>>
>
> A browser app is 100% new and comes from an untrusted source, in general.  Gecko/chrome JS usually comes from engineers with an existing reputation, and patches there build on a large body of existing knowledge and code.  Even then we get those reviews wrong and allow privacy/security bugs to slip through.

Do we intend to review any non-Mozilla apps? I don't see why we
should design APIs so it's easy to review apps we have no intention of
reviewing.

I think a better argument is that it would be very difficult to write
a correct browser using the API I proposed, because the list of
functions one needs to override is not explicit.

I think this is a fair point. I'm not convinced it outweighs the
downsides of (a) tightly coupling chrome JS to the browser app and (b)
spec'ing a gigantic, constantly-evolving API. But there isn't much
downside to trying this, since it wouldn't take us far astray from
having the content specify its own script to inject. So I'm OK trying
it this way.

>> Would you be happy if there was a chrome JS file which we inserted
>> into every mozbrowser content window, which forwarded information
>> back
>> up to the browser window?  I bet we could do this just as easily, if
>> not more easily, than my original proposal.
>>
>
> Oh, I thought that's what we were doing already.  Yes, I'm in favor of that because (IIUC) it's exposing a much smaller API surface area to content.  (Which presumably is consuming the information in the browser app context?)

What we're currently doing is writing code in Gecko which listens to
events and bubbles them up to the browser app. But it's much trickier
for things like alert() than doing it in chrome JS. At least, I
think. :)

> Like I said, TBH I think we'll eventually need to allow browser apps to inject arbitrary JS into content.  But I don't want to do that until a use case arises for which we have no other viable option.  If you know of such a use case already, then OK.

So long as we're the only browser app, injecting fixed chrome code
will always be viable. I'm not sure how this will change as we
support other browser apps. I guess we'll find out!

-Justin

[Ben Francis]

On Thu, Mar 8, 2012 at 1:09 AM, Chris Jones <cjo...@mozilla.com> wrote:

> Like I said, TBH I think we'll eventually need to allow browser apps to
> inject arbitrary JS into content. But I don't want to do that until a use
> case arises for which we have no other viable option. If you know of such
> a use case already, then OK.
>

In the meantime, how should we go about adding browser features like full
access to history from content, getting favicons for web pages, a "stop"
button...? Also alert(), confirm(), prompt() and open()? Should we create
new APIs for all of these things?
https://wiki.mozilla.org/WebAPI/EmbeddedBrowserAPI

Personally I'm not sure which is the right path. As a developer it's easier
to write against explicit APIs than mess around injecting code into
iframes, but I'm not sure that an API with such a large surface for such a
specific use case will be easy to standardise.

Ben

--
Ben Francis
http://tola.me.uk

[Matthew Phillips]

Ben, why is XHR insufficient for getting favicons?

[Justin Lebar]

On Mon, Mar 12, 2012 at 3:42 PM, Matthew Phillips
<mat...@phillipsoft.biz> wrote:
> Ben, why is XHR insufficient for getting favicons?

You have to get the favicon URL from the page. It's not always
http://foo.com/favicon.ico.

[Gervase Markham]

On 12/03/12 20:12, Justin Lebar wrote:
> You have to get the favicon URL from the page. It's not always
> http://foo.com/favicon.ico.

And hopefully, one day, it's never about that... Web server log spam,
restricted format, etc. etc.

Gerv

[Ben Francis]

On Mon, Mar 12, 2012 at 4:32 PM, Ben Francis <b...@krellian.com> wrote:

> On Thu, Mar 8, 2012 at 1:09 AM, Chris Jones <cjo...@mozilla.com> wrote:
>
>> Like I said, TBH I think we'll eventually need to allow browser apps to
>> inject arbitrary JS into content. But I don't want to do that until a use
>> case arises for which we have no other viable option. If you know of such
>> a use case already, then OK.
>>
>
> In the meantime, how should we go about adding browser features like full
> access to history from content, getting favicons for web pages, a "stop"
> button...? Also alert(), confirm(), prompt() and open()? Should we create
> new APIs for all of these things?
> https://wiki.mozilla.org/WebAPI/EmbeddedBrowserAPI
>

Development of Gaia's browser app is partially blocked on this. Should I
file bugs (if they don't already exist) for adding these features with the
current approach, or are we going to explore the alternative proposal
further? Or do both in parallel?

Thanks

[Chris Jones]

----- Original Message -----
> From: "Justin Lebar" <justin...@gmail.com>
> To: "Chris Jones" <cjo...@mozilla.com>
> Cc: "Ben Francis" <b...@krellian.com>, dev-w...@lists.mozilla.org
> Sent: Wednesday, March 7, 2012 9:14:50 PM
> Subject: Re: Browser API proposal
>

> >> > I agree that this API will be needed eventually, but I want to
> >> > hold
> >> > on it as long as possible.  I want this to be a nuclear
> >> > option, an extremely sensitive privilege, since reviewing the
> >> > behavior of a browser app that requests this is going to be
> >> > an amazingly hard problem.
> >>
> >> I don't understand why it should be any harder to review a browser
> >> app
> >> which requests this privilege than to review Gecko or chrome JS
> >> which
> >> implements this API.
> >>
> >
> > A browser app is 100% new and comes from an untrusted source, in
> > general.  Gecko/chrome JS usually comes from engineers with an
> > existing reputation, and patches there build on a large body of
> > existing knowledge and code.  Even then we get those reviews wrong
> > and allow privacy/security bugs to slip through.
>
> Do we intend to review any non-Mozilla apps? I don't see why we
> should design APIs so it's easy to review apps we have no intention
> of
> reviewing.
>

Mozilla might, yes. Other parties will likely also want to.

We already review add-ons so I'm not sure why this might be surprising.

> I think a better argument is that it would be very difficult to write
> a correct browser using the API I proposed, because the list of
> functions one needs to override is not explicit.
>
> I think this is a fair point. I'm not convinced it outweighs the
> downsides of (a) tightly coupling chrome JS to the browser app and
> (b)
> spec'ing a gigantic, constantly-evolving API. But there isn't much
> downside to trying this, since it wouldn't take us far astray from
> having the content specify its own script to inject. So I'm OK
> trying
> it this way.
>

I do think we'll want to load arbitrary script eventually, but I'd like that to be a nuclear option, with commensurate responsibility on possible review process.

Cheers,
Chris

[Justin Lebar]

> We already review add-ons so I'm not sure why this might be surprising.

We review add-ons because they are not sandboxed and can arbitrarily
destroy a user's browser and machine.

Web pages and web apps, in contrast, are sandboxed. I guess we might
want to review apps that we grant high privileges to, such as SMS or
raw TCP sockets. I don't feel like browser API privilege approaches
this high level of required trust, though.

[Chris Jones]

----- Original Message -----
> From: "Ben Francis" <b...@krellian.com>
> To: "Chris Jones" <cjo...@mozilla.com>
> Cc: "Justin Lebar" <justin...@gmail.com>, dev-w...@lists.mozilla.org
> Sent: Monday, March 12, 2012 9:32:05 AM
> Subject: Re: Browser API proposal
>
>

> On Thu, Mar 8, 2012 at 1:09 AM, Chris Jones < cjo...@mozilla.com >
> wrote:
>
>
> Like I said, TBH I think we'll eventually need to allow browser apps
> to inject arbitrary JS into content. But I don't want to do that
> until a use case arises for which we have no other viable option. If
> you know of such a use case already, then OK.
>
>
> In the meantime, how should we go about adding browser features like
> full access to history from content, getting favicons for web pages,
> a "stop" button...? Also alert(), confirm(), prompt() and open()?
> Should we create new APIs for all of these things?
> https://wiki.mozilla.org/WebAPI/EmbeddedBrowserAPI
>

Yes, I'd like to see how far we can get on these as well-defined and scoped APIs.

> Personally I'm not sure which is the right path. As a developer it's
> easier to write against explicit APIs than mess around injecting
> code into iframes, but I'm not sure that an API with such a large
> surface for such a specific use case will be easy to standardise.
>

An API for injecting arbitrary script into iframes and messaging through secret non-postMessage() channels is going to be extremely difficult to standardize as well.

Cheers,
Chris

[Chris Jones]

----- Original Message -----
> From: "Justin Lebar" <justin...@gmail.com>
> To: "Chris Jones" <cjo...@mozilla.com>

> Cc: "Ben Francis" <b...@krellian.com>, dev-w...@lists.mozilla.org

> Sent: Wednesday, March 14, 2012 6:12:47 PM
> Subject: Re: Browser API proposal
>

> > We already review add-ons so I'm not sure why this might be
> > surprising.
>
> We review add-ons because they are not sandboxed and can arbitrarily
> destroy a user's browser and machine.
>
> Web pages and web apps, in contrast, are sandboxed. I guess we might
> want to review apps that we grant high privileges to, such as SMS or
> raw TCP sockets. I don't feel like browser API privilege approaches
> this high level of required trust, though.
>

Yes, privileges imply review is the idea. A web browser application is a huge potential privacy leak. A store might want to make sure it's not phoning home about every action the user makes. Mozilla wouldn't r+ such a browser app, I suspect.

Cheers,
Chris

> On Wed, Mar 14, 2012 at 9:09 PM, Chris Jones <cjo...@mozilla.com>
> wrote:

> > ----- Original Message -----
> >> From: "Justin Lebar" <justin...@gmail.com>
> >> To: "Chris Jones" <cjo...@mozilla.com>

> >> Cc: "Ben Francis" <b...@krellian.com>, dev-w...@lists.mozilla.org
> >> Sent: Wednesday, March 7, 2012 9:14:50 PM

> >> Subject: Re: Browser API proposal
> >>

[Mounir Lamouri]

Hi,

AFAIK, right now, all applications in B2G are in an <iframe mozbrowser>,
the browser app like the other apps.

If I understood it correctly, the reason why non-browser apps are inside
an <iframe mozbrowser> is to prevent frame busting and also let the
application believe it's is not inside an iframe because some
application are "remote" like the Facebook app that is loading
m.facebook.com and websites very often check that they are not inside an
iframe and behave differently in that case.
The frame busting should be fixable with the sandbox attribute [1] on
the iframe element but faking that the iframe is at the top level is
harder. We could add another proprietary attribute to the iframe element
but I don't think there is a real usage for that in the web in general.
Another solution would be to create a brand new element like
<application> that would be like an iframe but with all specificities
required for an application. However, that seems a bit too much.
Instead, I tend to think we should not worry about applications that
check if they are at the top level window. Indeed, that seems completely
reasonable for a website that aims to be opened by a browser to check
that but an installed web app shouldn't behave the same way.

Basically, that would create a distinction between installed web apps
and bookmarked websites. Bookmarked websites would be websites with an
icon in the user homescreen that will open a browser without a UI (aka
<iframe mozbrowser> for the moment) but installed web apps will be
opened inside an <iframe sandbox>.

The second point I would like to rise is to use <browser> instead of
<iframe mozbrowser>. I think <browser> is nicer regarding semantic. It
will also prevent us to take all the iframe stuff we might not really
need and will make the Browser API (or whatever the name is) easier to
standardized (and likely implement) because more isolated.
I have the feeling that specializing <iframe> behavior for the browser
app has been done because the iframe represents a nested browsing
context. However, there are other elements in HTML that represents a
nested browsing context (like <object> or <frame>) so adding one doesn't
seem wrong. Unless we need some specific features the <iframe> has or
there is a strong semantic link between those.

I would be very interested to hear your feedback about this. Especially
Justin, Olli and Ben Francis who, I believe, have been working on the
Browser app and API.

[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#attr-iframe-sandbox

Cheers,
--
Mounir

[Justin Lebar]

> Instead, I tend to think we should not worry about applications that
> check if they are at the top level window.

I disagree with this.

Many web apps will be thin layers around web pages. Many web pages
won't load if they detect that they're framed.

So if we allow an app to observe that it's framed, developers will
need to remove their frame detection code in order to make their page
a working web app. We already observed this in the case of the
Facebook app, which did not work until we hid from it the fact that it
was framed. I suspect this will not be an anomaly.

I think for right now, there's no reason not to serve apps and
webpages using the same tag, be it <iframe mozbrowser> or <browser> or
whatever.

Additionally, <iframe mozbrowser> would theoretically let us do a
number of things to apps that we otherwise wouldn't be able to do
(mozbrowser currently doesn't do any of these things, but it will):

* Get the app's favicon
* Display a throbber when the app is accessing the network
* "Freeze" the app, so its timeouts stop firing
* Detect if the app is using SSL

I'm not worried about the security risk of allowing Gaia to do things
like read the exact location of the app window or do other browser-y
things to the app. Gaia can do lots of other, more malicious things.

I don't think <iframe mozbrowser> or <browser> really captures what
we're doing here. Maybe <pokable_sandbox>. :)

[Ben Francis]

On Fri, Mar 16, 2012 at 6:07 PM, Mounir Lamouri <mou...@lamouri.fr> wrote:

> AFAIK, right now, all applications in B2G are in an <iframe mozbrowser>,
> the browser app like the other apps.
>

Most of them are, yes. But Chris Jones has suggested that we create another
iframe attribute called "mozapp" which has a subset of the mozbrowser
functionality. This is because the homescreen doesn't necessarily need all
the privileges over app content that the browser app needs over web page
content. Chris has suggested that mozapp iframes should be a black box that
the homescreen can't look into, but that acts as a window.top boundary and
ignores X-Frame Options headers like mozbrowser does. I only think we
should look to create this if there are clearly distinct use cases for the
two.

Another alternative is to use a similar syntax to <iframe sandbox> where
you turn mozbrowser features on and off at a more granular level, so you
could create an <iframe mozbrowser> that just acts as a window.top boundary
but doesn't have any other features like emitting events and allowing
access to history for example. The other extreme would be to propose two
new HTML elements <browser> and <window>!

>
> If I understood it correctly, the reason why non-browser apps are inside
> an <iframe mozbrowser> is to prevent frame busting and also let the
> application believe it's is not inside an iframe because some
> application are "remote" like the Facebook app that is loading
> m.facebook.com and websites very often check that they are not inside an
> iframe and behave differently in that case.
>

That is correct and there's nothing special about the browser app in this
regard. The browser app is actually an <iframe mozbrowser> that contains a
nested <iframe mozbrowser> in which web page content is loaded. The nested
iframe is actually the one which uses all the mozbrowser features in that
the outer iframe can listen for cross-origin events which wouldn't usually
escape out of the inner iframe like loadstart, loadstop and locationchange.

> The frame busting should be fixable with the sandbox attribute [1] on
> the iframe element but faking that the iframe is at the top level is
> harder. We could add another proprietary attribute to the iframe element
> but I don't think there is a real usage for that in the web in general.
> Another solution would be to create a brand new element like
> <application> that would be like an iframe but with all specificities
> required for an application. However, that seems a bit too much.
> Instead, I tend to think we should not worry about applications that
> check if they are at the top level window. Indeed, that seems completely
> reasonable for a website that aims to be opened by a browser to check
> that but an installed web app shouldn't behave the same way.
>

A lot of web sites check that they're not inside an iframe and either try
to bust out of it or refuse to render, usually to prevent phishing. We
should allow this to continue to happen for non-mozbrowser or non-mozapp
iframes.

If we wanted touch.facebook.com to become an Open Web App, we couldn't ask
that they turn off their frame busting, because it's still necessary on
other platforms. I think its likely that many "apps" may be used both as an
installed web app and as a web site in a standard browser.

>
> Basically, that would create a distinction between installed web apps
> and bookmarked websites. Bookmarked websites would be websites with an
> icon in the user homescreen that will open a browser without a UI (aka
> <iframe mozbrowser> for the moment) but installed web apps will be
> opened inside an <iframe sandbox>.
>

We could potentially load bookmarks in an <iframe mozbrowser> and apps in
an <iframe mozapp> or <iframe sandbox> if that fulfils all the
requirements. What user interface elements are displayed is a separate UX
issue.

>
> The second point I would like to rise is to use <browser> instead of
> <iframe mozbrowser>. I think <browser> is nicer regarding semantic. It
> will also prevent us to take all the iframe stuff we might not really
> need and will make the Browser API (or whatever the name is) easier to
> standardized (and likely implement) because more isolated.
>

I wouldn't be opposed to this. I also wouldn't be opposed to proposing a
<window> or <app> element to wrap apps in and make it easier for a
homescreen as a web app to act as a window manager - but I struggle to see
the incentive for other vendors to implement these HTML elements.

> I have the feeling that specializing <iframe> behavior for the browser
> app has been done because the iframe represents a nested browsing
> context. However, there are other elements in HTML that represents a
> nested browsing context (like <object> or <frame>) so adding one doesn't
> seem wrong. Unless we need some specific features the <iframe> has or
> there is a strong semantic link between those.
>

I think it's more because proposing a new HTML element seems like a bigger
jump when an ordinary iframe and a mozbrowser iframe have so much in
common, but perhaps this isn't the case.

[Mounir Lamouri]

On 03/16/2012 07:41 PM, Justin Lebar wrote:
>> Instead, I tend to think we should not worry about applications that
>> check if they are at the top level window.
>

> I disagree with this.
>
> Many web apps will be thin layers around web pages. Many web pages
> won't load if they detect that they're framed.
>
> So if we allow an app to observe that it's framed, developers will
> need to remove their frame detection code in order to make their page
> a working web app. We already observed this in the case of the
> Facebook app, which did not work until we hid from it the fact that it
> was framed. I suspect this will not be an anomaly.

I've never used an app like that but I can imagine that some app might
behave that way like YourFavoriteNewsPaper App or
YourFavoriteSocialNetwork App or even Wikipedia app might be like that.
I guess those apps should be bookmarks instead of applications but
that's not something we can have an action on.
However, I would easily buy the argument that code might be shared
between an app and a regular content and that code might contain frame
busting and top level checks. Making this unwanted in an app would be
bothering for developers. Also, I would buy that if we want to make an
OS on top of the web platform, we should just follow what the web
platforms norms are, even those that have been imposed by the content...

> I think for right now, there's no reason not to serve apps and
> webpages using the same tag, be it <iframe mozbrowser> or <browser> or
> whatever.

Apps and browser have different needs.

> Additionally, <iframe mozbrowser> would theoretically let us do a
> number of things to apps that we otherwise wouldn't be able to do
> (mozbrowser currently doesn't do any of these things, but it will):
>
> * Get the app's favicon

Apps don't need that, it's very likely specified in the OWA manifest and
can't be changed.

> * Display a throbber when the app is accessing the network

I don't see why *we* should handle that? IMO, that we should be shown by
the app. What other platforms do?

> * "Freeze" the app, so its timeouts stop firing

If we want to do that for an app, that will be handled by Gecko or the
Task Manager (with some privileges), right?

> * Detect if the app is using SSL

I'm not sure why we need to know that... And who needs to know that?

> I'm not worried about the security risk of allowing Gaia to do things
> like read the exact location of the app window or do other browser-y
> things to the app. Gaia can do lots of other, more malicious things.
>
> I don't think <iframe mozbrowser> or <browser> really captures what
> we're doing here. Maybe <pokable_sandbox>. :)

The main purpose of my proposal isn't security but semantic and
cleanliness. Using <iframe mozbrowser> seems like defining forms with
<div form> instead of <form> because <div> are what a <form> is so we
can just add an attribute that says that we want this div to behave like
a form...

--
Mounir

[Justin Lebar]

There are two separate proposals here. One is to replace <iframe
mozbrowser> with <browser>, and the other is to separate the tags used
by apps and browsers.

I understand that the needs of apps are a subset of the needs of
browsers. The question is whether it is therefore inappropriate to
use the same tag for browsers and apps. This is significant inasmuch
as it impacts the tag's name.

Use-cases shared by browsers and apps:

>> * Display a throbber when the app is accessing the network
> I don't see why *we* should handle that? IMO, that we should be shown by
> the app. What other platforms do?

What about on the app's initial load? If it's loading from the
network, and we might want to display a throbber.

>> * "Freeze" the app, so its timeouts stop firing
>
> If we want to do that for an app, that will be handled by Gecko or the
> Task Manager (with some privileges), right?

The freezing will be handled by Gecko, but we have to tell Gecko to
freeze the window! We need some method to call.

I'm OK with <browser> if you want to write the patch. But then
sticking apps inside a "<browser>" seems wrong. So I'd rather us come
up with a different name, which expresses what <browser> and <app> are
both for. "<app>" isn't necessarily for "apps" -- an <app> is just a
less-privileged version of a <browser>.

[Mounir Lamouri]

For information, Justin and I had a quick chat on IRC yesterday and we
agreed that we could at least go for a <browser> element instead of an
<iframe mozbrowser> and then, we should see if we need to change the
name of the element or create another one for applications handling (for
the moment, we will just have applications in a <browser>).

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

This said, we will need someone to write the patch and Justin doesn't
seem very excited about that. If there is any volunteer..?

If you have any objections with this plan, please speak up.

Cheers,
--
Mounir

[Andreas Gal]

New elements are ridiculously hard to standardize. What is the advantage of the new element over using iframe?

Andreas

[Mounir Lamouri]

On 03/22/2012 10:59 AM, Andreas Gal wrote:
>
> New elements are ridiculously hard to standardize. What is the advantage of the new element over using iframe?

I wonder what makes you think that? I've never been in the process of
standardizing a new element but it seems to me that it will be much
easier than standardizing this new attribute in the iframe element.

As I already said in that thread, using an element would be better
regarding semantic: <iframe browser> is nothing better than <div form>
for <form>. You are defining an entire behavioral and semantic change
based on an attribute.
Also, regarding standardization, if we add a new attribute to <iframe>,
we will have to make it work with other <iframe>'s attribute. What
should happen if we have <iframe browser sandbox>?
Furthermore, what would happen if we a UA that doesn't support <iframe
browser> tries to show a page with it? It will show a simple <iframe>
and the page will be completely broken. Using a new element helps the
developer to set a fa[lback in the element's content.
Finally, having seen some comments from Ian about browsers written in
HTML, I think it will be very hard to make a browser attribute
standardized in the iframe element. It might be harder if the
functionality is contained in a new element. Though, we should probably
ask him. Also, I guess it might be easier to have this new element being
an extension to the HTML specifications than an attribute being an
extension to an already complex HTML element. We would be less dependent
on changes in the HTML specifications.

--
Mounir

[Justin Lebar]

On Thu, Mar 22, 2012 at 5:53 AM, Mounir Lamouri <mou...@lamouri.fr> wrote:
> For information, Justin and I had a quick chat on IRC yesterday and we
> agreed that we could at least go for a <browser> element instead of an
> <iframe mozbrowser> and then, we should see if we need to change the
> name of the element or create another one for applications handling (for
> the moment, we will just have applications in a <browser>).

To be clear, my position is that I don't care whether we use <iframe
mozbrowser> or <browser>.

There's a good semantic argument in favor of using <browser>. But if
there are mitigating arguments, such as difficulty of standardization,
then perhaps we should continue using <iframe mozbrowser>.

mozbrowser is going to be ridiculously difficult to standardize in any
case, fwiw.

> As I already said in that thread, using an element would be better
> regarding semantic: <iframe browser> is nothing better than <div form>
> for <form>. You are defining an entire behavioral and semantic change
> based on an attribute.

I disagree with this argument. I don't think <iframe browser> is a
lot different than <iframe sandbox>, in terms of behavior changes and
semantics. It's nowhere near <div form>.

> Also, regarding standardization, if we add a new attribute to <iframe>,
> we will have to make it work with other <iframe>'s attribute. What
> should happen if we have <iframe browser sandbox>?

We can just spec that this formats the user's hard drive.

Seriously, we don't need to make it work properly -- we can say that
you get sandbox or browser but not both.

> Furthermore, what would happen if we a UA that doesn't support <iframe
> browser> tries to show a page with it? It will show a simple <iframe>
> and the page will be completely broken. Using a new element helps the
> developer to set a fa[lback in the element's content.

This is an important point...

On the one hand, it's good that the developer can specify fallback content.

On the other hand, that fallback is almost certainly going to be an
<iframe>. Either that, or it's going to be a message saying "this
won't work on your machine."

> Finally, having seen some comments from Ian about browsers written in
> HTML, I think it will be very hard to make a browser attribute
> standardized in the iframe element. It might be harder if the
> functionality is contained in a new element. Though, we should probably
> ask him.

Hixie thinks we're never going to standardize this API.

[Ben Francis]

On Mon, Mar 19, 2012 at 3:42 PM, Ben Francis <b...@krellian.com> wrote:

> On Fri, Mar 16, 2012 at 6:07 PM, Mounir Lamouri <mou...@lamouri.fr> wrote:
>
>> The second point I would like to rise is to use <browser> instead of
>> <iframe mozbrowser>. I think <browser> is nicer regarding semantic. It
>> will also prevent us to take all the iframe stuff we might not really
>> need and will make the Browser API (or whatever the name is) easier to
>> standardized (and likely implement) because more isolated.
>>
>
> I wouldn't be opposed to this. I also wouldn't be opposed to proposing a
> <window> or <app> element to wrap apps in and make it easier for a
> homescreen as a web app to act as a window manager - but I struggle to see
> the incentive for other vendors to implement these HTML elements.
>

Just to expand on this a little... from the point of view of writing a web
browser as a web app it would be great if there was an HTML equivalent of
XUL's <browser> element, with methods and properties like canGoBack,
canGoForward, contentTitle, currentURI, sessionHistory, webBrowserFind,
webProgress, goBack, goForward, loadURI, reload, reloadWithFlags and stop.
https://developer.mozilla.org/en/XUL/browser. Currently most of these
things are not possible with an iframe, due in part to the same-origin
policy.

The main problems I see with this are:

1. A lot of these methods are synchronous so probably wouldn't work if
each browser element is in its own process. But we could come up with
asynchronous alternatives.
2. I can't think of any incentive for Chrome, Safari or Opera to
implement this. That isn't to say that there aren't other use cases for it
or that other people wouldn't use it, but I imagine that getting enough
consensus to make <browser> part of HTML5 (or "HTML5.1") could be difficult.

The only alternative that's really been put forward is to create a generic
API that allows privileged content to inject arbitrary JavaScript into an
iframe. This would make the development of a browser app significantly more
difficult and raises even more security issues.

If neither of these approaches can become a web standard then the only
options I see remaining are a perpetually vendor-prefixed mozbrowser
attribute, or writing the browser UI in chrome which I think we're trying
to avoid.

Chris Jones has identified that apps also need special kinds of iframes
inside our "window manager" so that they have their own window.top boundary
and can be run in separate processes for example. This could either be a
<browser> element (but you might not always want to give a window manager
the same privileges over an app that a browser has over a web site), or an
HTML equivalent of XUL's <window> element (although it would be very
different to <xul:window>).

For the long term I've been discussing with Firefox UX folks the
possibility of making a lot of browser features (like awesomescreen,
history and bookmarks) part of the Gaia homescreen app, but for all the B2G
milestones from M2.5 to M5.2 it's looking like we'll have a standalone
browser-as-webapp in Gaia that looks a lot like Fennec and that this could
be one of the two most important apps for our partners during that period.

Whatever happens, we need a way to create web browser like functionality in
Gaia and I'd be very grateful if anyone on the WebAPI team could help me
with figuring out how we can do this as I'll be working quite intensively
on the browser app from the beginning of April.

Thanks

[Mounir Lamouri]

On 03/26/2012 04:31 AM, Ben Francis wrote:
> Just to expand on this a little... from the point of view of writing a web
> browser as a web app it would be great if there was an HTML equivalent of
> XUL's <browser> element, with methods and properties like canGoBack,
> canGoForward, contentTitle, currentURI, sessionHistory, webBrowserFind,
> webProgress, goBack, goForward, loadURI, reload, reloadWithFlags and stop.
> https://developer.mozilla.org/en/XUL/browser. Currently most of these
> things are not possible with an iframe, due in part to the same-origin
> policy.

If having those properties instead of async events would make
developer's life easier, I think that's a good point for <browser>.

> If neither of these approaches can become a web standard then the only
> options I see remaining are a perpetually vendor-prefixed mozbrowser
> attribute, or writing the browser UI in chrome which I think we're trying
> to avoid.

That is a different problem. Making this API a standard should not
influence how we make the API. We should make sensible choices. If our
decisions seem reasonable, it will be easier to make this a web standard.
However, if for some political/general vision reasons, this API is
rejected, the implementation details will not change anything.

--
Mounir

[Chris Jones]

----- Original Message -----
> From: "Justin Lebar" <justin...@gmail.com>

> To: "Mounir Lamouri" <mou...@lamouri.fr>
> Cc: dev-w...@lists.mozilla.org
> Sent: Wednesday, March 21, 2012 9:14:38 AM
> Subject: Re: <browser> and <iframe sandbox> instead of <iframe mozbrowser>?
>
> I understand that the needs of apps are a subset of the needs of
> browsers. The question is whether it is therefore inappropriate to
> use the same tag for browsers and apps. This is significant inasmuch
> as it impacts the tag's name.
>

That's not true, neither is a subset of the other. Nor is <iframe sandbox> a subset of either.

Ignoring sytax, the high-level motivation for <iframe mozbrowser> is to *expose* information to the parent document that's usually hidden for security reasons.

On the other hand, the motivation for <iframe mozapp> is (i) completely isolate it from external content and (ii) strongly associate a manifest with the content inside the frame, deep within the bowels of the engine.

Cheers,
Chris

[Justin Lebar]

>> I understand that the needs of apps are a subset of the needs of
>> browsers.  The question is whether it is therefore inappropriate to
>> use the same tag for browsers and apps.  This is significant inasmuch
>> as it impacts the tag's name.
>>
> That's not true, neither is a subset of the other.  Nor is <iframe sandbox> a subset of either.
>
> Ignoring sytax, the high-level motivation for <iframe mozbrowser> is to *expose* information to the parent document that's usually hidden for security reasons.
>
> On the other hand, the motivation for <iframe mozapp> is (i) completely isolate it from external content and (ii) strongly associate a manifest with the content inside the frame, deep within the bowels of the engine.

A purpose of <app> which was left out from the list above is to
isolate the window manager from the app. In this sense, it's exactly
like browser.

Additionally, as I've said earlier, there are some things about an
<app> that we might want to expose that we don't expose on normal
iframes. For example, there may be cases when we load an app entirely
off the network. In that case, we may wish to display a throbber.
That's a feature which will be shared with mozbrowser.

There are other details which will be common to mozbrowser and app,
such as handling of window.alert/open and <a target="_blank">. These
don't have to do with isolating the browser / app from external
content, but rather have to do with the reverse, isolating the window
manager from the browser/app. Similarly, app and mozbrowser will both
need to isolate their session history from the larger browsing context
-- this is again a matter of isolating the window manager from the
browser/app, not vice versa.

Iframe sandbox too may share features with both browser and app. In
particular, <iframe sandbox> implies that the sandboxed iframe may not
navigate other browsing contexts (e.g. via <a target="foo">). We may
share this too with mozbrowser and app.

I don't care what HTML tags we use, but it's important to recognize
that there are a large number of shared features between mozbrowser
and app.

-Justin