Synthesizing native shells for web apps
Michael
We have an experimental prototype that, when the user installs a web
application on a desktop OS, synthesizes a native app. It does this
by copying a generic xulrunner (or firefox -app) launcher and
customizing a boilerplate XUL app into a stable location (in %APP_DATA
% in Windows, in the .app bundle on Mac). The prototype is intriguing
but there's obviously a lot to do before the application feels well-
integrated with the user's web and native experiences.
I'd split the conversation into a couple points:
1. Profile access and management
The simple approach of spinning up a new xulrunner app obviously
creates a new profile, running a fresh Gecko runtime. While this is
simple, and clearly isolated from Firefox, it has a number of
problems. A short list of issues include loss of cookie and local
storage context, wasteful and slow recaching of data, loss of form
history, and lack of extensibility. Some kind of profile isolation
does make sense, though - if the user thinks of an application as
being "outside" Firefox, they wouldn't expect their history to be
shared.
Should we pursue a Firefox-chromeless mode? Should we find a way to
do cross-process profiles? Many people have thought long and hard
about this problem; please share your thoughts!
2. Creation of content windows, integration with "app-level" eventing
and menus
At a minimum, the application needs to create a native window and
instantiate a browser element into it. This part is fairly
straightforward, though details remain: how should the window's
characteristics be set? can the window set the native menubar?
On OSes that support multi-window document-oriented applications, it
would be nice to let the application interact with application-level
events. How should application-level events like "open this
document", "make a new document" or "quit now" be exposed? How could
system level navigation APIs like the Task Bar's "jump lists" and the
Docks's "command shortcuts" be exposed? How about interactions with
OS-level content-type handler APIs?
3. Integration between the app-browser and the user's default browser
Web app developers would like to be able to expect content will not be
able to navigate away from the top level domain of their application.
This probably means that navigation events that would cause this to
happen are caught by the runtime and sent to the OS for normal "open
this URL" behavior. A complication is that, to support federated
login and service APIs, the application would like to be able to
provide a list of domains (or URLs) that should not trigger this
behavior.
The work that has already been done on pinned tabs should be reusable
here.
4. Lifecycle management of installed apps
First run: Users have been taught to expect a long delay before an
internet-distributed application is launchable. This doesn't quite
fit our current app cache model. Can we "spool off" a first-run app
cache load in a way that feels natural to the user, and provides good
feedback?
Dependencies on Firefox runtime: If we depend on a Firefox runtime,
the user may run afoul of application dependencies that are
mysterious. Do we need to install a Firefox library in a location
that is less likely to be destroyed or modified? Similarly, on
platforms that support "uninstall", the dependency graph between
Firefox and an application that is "powered by Firefox" could be
confusing and potentially brittle.
(There was some older work on this in bug 299989, but fresh eyes can
help)
There's a lot to do here - please share your insights!
-mh
Ted Mielczarek
Webrunner, which grew out of a previous labs experiment (Prism):
http://www.salsitasoft.com/webrunner/
Have you talked to Matt Gertner about leveraging what he's already doing there?
-Ted
Benjamin Smedberg
> Following up on the quick briefing in the platform meeting today.
>
> We have an experimental prototype that, when the user installs a web
> application on a desktop OS, synthesizes a native app. It does this
> by copying a generic xulrunner (or firefox -app) launcher and
> customizing a boilerplate XUL app into a stable location (in %APP_DATA
> % in Windows, in the .app bundle on Mac). The prototype is intriguing
> but there's obviously a lot to do before the application feels well-
> integrated with the user's web and native experiences.
>
> I'd split the conversation into a couple points:
describe/decide the UI experience we actually want. This will greatly
affect how we implement profile and process management. I pretty
strongly believe that we want an almost fully shared browsing session,
even if the apps are presented separately (in the dock/taskbar/start
menu/whatever). However, we should consider having separate "sessions":
that is, we would share permanent state (including global history,
cookies, cache, appcache, etc), but only different session cookies and
sessionstores.
I know that Ehsan has already been thinking about how we could manage
separate session cookies in a single process; I don't know how far along
that process is currently, but I think we could prioritize and fix it
fairly quickly.
If this is the UI we decide upon, then I don't think that the
webrunner/prism model is at all what we want. Instead, the guts of all
of these windows should be run by a single main Firefox process. The
constructed apps would merely be lightweight shells which display
Firefox content in a different form of UI. This is very easy to
implement on Windows and Linux. On Mac, it may require a little bit of
extra work because of how dock icons typically behave. I don't know
exactly how we could achieve this on Android, but I suspect it would be
possible.
As soon as we have content processes, we can make policy decisions to
run apps and app tabs in a separate content process. This gives us the
responsiveness/crash protection that users would expect from running a
"separate app" without dealing with the huge complexity of separate
profiles and dealing with app profile management.
I'm not yet clear on how this would behave if the user decided to
uninstall Firefox: on Windows this sounds solvable, but uninstall on Mac
is very much just dragging /Applications/Firefox.app to the trash. We
might need to provide a stub install mechanism so that if you launch a
webapp and Firefox is not available, we redownload Firefox in order to
launch the app.
--BDS
Matthew Gertner
> On 8/2/2011 6:20 PM, Michael wrote:
>
>> Following up on the quick briefing in the platform meeting today.
>>
>> We have an experimental prototype that, when the user installs a web
>> application on a desktop OS, synthesizes a native app. It does this
>> by copying a generic xulrunner (or firefox -app) launcher and
>> customizing a boilerplate XUL app into a stable location (in %APP_DATA
>> % in Windows, in the .app bundle on Mac). The prototype is intriguing
>> but there's obviously a lot to do before the application feels well-
>> integrated with the user's web and native experiences.
>>
>> I'd split the conversation into a couple points:
>>
> Before we get into the technical discussion much, I think we need to
> describe/decide the UI experience we actually want. This will greatly affect
> how we implement profile and process management. I pretty strongly believe
> that we want an almost fully shared browsing session, even if the apps are
> presented separately (in the dock/taskbar/start menu/whatever). However, we
> should consider having separate "sessions": that is, we would share
> permanent state (including global history, cookies, cache, appcache, etc),
> but only different session cookies and sessionstores.
>
My experience has led me to the opposite conclusion: users mostly want a
completely separate browsing session. What use cases make you feel that a
shared browsing session is desirable?
Matt
Matthew Gertner
As Ted says, there's a lot of overlap here with what WebRunner does today.
Getting the native shells to work on all platforms was a non-trivial effort
so it might make sense to look at the code that's there (which is all MPL
and originated in Mozilla Labs). To your specific points:
1. Profile access and management
> The simple approach of spinning up a new xulrunner app obviously
> creates a new profile, running a fresh Gecko runtime. While this is
> simple, and clearly isolated from Firefox, it has a number of
> problems. A short list of issues include loss of cookie and local
> storage context, wasteful and slow recaching of data, loss of form
> history, and lack of extensibility. Some kind of profile isolation
> does make sense, though - if the user thinks of an application as
> being "outside" Firefox, they wouldn't expect their history to be
> shared.
>
I'm not sure that there is a right and wrong way to do this, but rather a
set of trade-offs depending on whether profiles are app-specific or shared.
In my experience working with WebRunner users, some of the most valued
features stem from the ability to isolate profiles. This has some security
benefits (e.g. no cookie hijacking). Also, a common case is to have multiple
apps for e.g. different Google apps that use different user accounts.
Add-ons can be installed specifically for certain domains, which reduces the
total number of extensions installed in a given profile (lowering risk of
conflicts, performance impact, etc.).
Trying to share a profile isn't clearly better and it is much more complex.
In my opinion the best approach is to copy stuff (prefs, extensions, cookies
and passwords for the relevant domain, etc.) into the new profile of the app
when it is spun off and then leave the profiles separate. WebRunner already
does this with proxy settings. If there is a feeling that existing apps
should "inherit" new/changed prefs from the main Firefox profile when they
are changed, the stub could migrate them over whenever an app is started.
> Should we pursue a Firefox-chromeless mode? Should we find a way to
> do cross-process profiles? Many people have thought long and hard
> about this problem; please share your thoughts!
>
I didn't have any problem using XUL overlays to strip off all browser
chrome.
> 2. Creation of content windows, integration with "app-level" eventing
> and menus
> At a minimum, the application needs to create a native window and
> instantiate a browser element into it. This part is fairly
> straightforward, though details remain: how should the window's
> characteristics be set? can the window set the native menubar?
>
WebRunner simply runs Firefox with a custom stub and special command-line
option. Each app has its own profile and process. This means that the app
automatically has all the characteristics a user expects: dock icon on Mac,
taskbar button on Window, menu bar, process ID, etc. Since the web app is a
fully fledged desktop app, you can do cool things like making your Gmail app
be the system default email app (for mailto: links, Windows send to mail
recipient, etc.).
> On OSes that support multi-window document-oriented applications, it
> would be nice to let the application interact with application-level
> events. How should application-level events like "open this
> document", "make a new document" or "quit now" be exposed? How could
> system level navigation APIs like the Task Bar's "jump lists" and the
> Docks's "command shortcuts" be exposed? How about interactions with
> OS-level content-type handler APIs?
>
If you make Firefox your runtime you don't have to worry about this. Again,
since it's a real app you can you normal OS APIs to create content handlers
(WebRunner has APIs for this on Windows, Mac and Linux).
> 3. Integration between the app-browser and the user's default browser
> Web app developers would like to be able to expect content will not be
> able to navigate away from the top level domain of their application.
> This probably means that navigation events that would cause this to
> happen are caught by the runtime and sent to the OS for normal "open
> this URL" behavior. A complication is that, to support federated
> login and service APIs, the application would like to be able to
> provide a list of domains (or URLs) that should not trigger this
> behavior.
>
WebRunner uses an overlay to catch navigate events and redirect them to the
default OS app (e.g. for HTTP) if they are not in the appropriate domain.
Exceptions (domains to explicitly include/exclude can be configured in
webapp.ini using wildcards).
> 4. Lifecycle management of installed apps
> First run: Users have been taught to expect a long delay before an
> internet-distributed application is launchable. This doesn't quite
> fit our current app cache model. Can we "spool off" a first-run app
> cache load in a way that feels natural to the user, and provides good
> feedback?
>
Cool idea.
> Dependencies on Firefox runtime: If we depend on a Firefox runtime,
> the user may run afoul of application dependencies that are
> mysterious. Do we need to install a Firefox library in a location
> that is less likely to be destroyed or modified? Similarly, on
> platforms that support "uninstall", the dependency graph between
> Firefox and an application that is "powered by Firefox" could be
> confusing and potentially brittle.
>
This is a tricky problem and one that WebRunner frankly doesn't address very
well right now. One thing that needs to be ensured is that FIrefox can
update properly even if webapps are using the same binaries. Some of this
was fixed in a bug that I'd have to dig up (Benjamin might know) but it's
probably not a 100% solved problem. I think it could be solved with changes
to Firefox (i.e. checking explicitly for other running instances when
updating) and that this is probably better than creating a whole new copy of
the runtime and maintaining that separately.
I like Benjamin's idea of having the stub download a new version of the
runtime if the old one is not in the expected place.
Matt
Matthew Gertner
Founder and Chief Executive Officer <http://www.salsitasoft.com/>Email:
mat...@salsitasoft.com – Mobile: +420 603507882 – Skype: matthewgertner
Benjamin Smedberg
>
>
> My experience has led me to the opposite conclusion: users mostly want
> a completely separate browsing session. What use cases make you feel
> that a shared browsing session is desirable?
>
the browser. Maybe if it's nice, you will pin it as an app tab, and
eventually decide to push into its own window. Maybe you'll decide you
don't want it in a separate window and move it back into an app tab. If
you have to start over with a separate local store and cache during the
transition, that will be painful. This is especially true as we start to
use the browser as an identity broker.
Also, I believe many people want visited sites to be colored correctly
across whatever apps they are using (I am of course extending my own
personal preference to others). If I see the same link in Google Reader
and in gmail (which is pretty common), I want to know that I've already
visited or bookmarked it.
--BDS
Matthew Gertner
> I believe that the common use case will be to start visiting a site in the
> browser. Maybe if it's nice, you will pin it as an app tab, and eventually
> decide to push into its own window. Maybe you'll decide you don't want it in
> a separate window and move it back into an app tab. If you have to start
> over with a separate local store and cache during the transition, that will
> be painful. This is especially true as we start to use the browser as an
> identity broker.
>
Sure, I totally agree that people will tend to start in the browser and then
spin off a separate app for certain sites. That's exactly what WebRunner
does. To the extent that local store and cache are significant they can be
copied over as I proposed before. It would be awesome if they were shared
but simply copying the existing one into the app is probably a good 80/20
solution.
>
> Also, I believe many people want visited sites to be colored correctly
> across whatever apps they are using (I am of course extending my own
> personal preference to others). If I see the same link in Google Reader and
> in gmail (which is pretty common), I want to know that I've already visited
> or bookmarked it.
>
> This strikes me as more "nice to have" than a deal breaker. In my
experience most of the apps that people use with WebRunner are more web apps
in the classic sense rather than documents that contain a lot of links. I'm
not saying this never happens but it shouldn't drive the decision of how to
architect the solution.
It would be awesome to have the ability to share profiles wholly or
partially between different Firefox instances, and as Mike says, this has
been discussed and written about at length. But this is an orthogonal issue
to the question of how to architect the native shells. Since there is a
working solution based on Mozilla technologies that originated inside
Mozilla and has a few years of history in the world, wouldn't it make sense
to use that as a starting point? Stuff like shared profiles and lightweight
content-rendering processes can be taken advantage of once they are
implemented.
This certainly doesn't mean WebRunner couldn't be improved in many ways of
course!
Matt
Ehsan Akhgari
>> This strikes me as more "nice to have" than a deal breaker. In my
> experience most of the apps that people use with WebRunner are more web apps
> in the classic sense rather than documents that contain a lot of links. I'm
> not saying this never happens but it shouldn't drive the decision of how to
> architect the solution.
>
> It would be awesome to have the ability to share profiles wholly or
> partially between different Firefox instances, and as Mike says, this has
> been discussed and written about at length. But this is an orthogonal issue
> to the question of how to architect the native shells. Since there is a
> working solution based on Mozilla technologies that originated inside
> Mozilla and has a few years of history in the world, wouldn't it make sense
> to use that as a starting point? Stuff like shared profiles and lightweight
> content-rendering processes can be taken advantage of once they are
> implemented.
As Benjamin mentioned, this is something that we need to answer first
before delving into the technical sides of it. Depending on which
behavior we want, the technical requirements to realize them are going
to be hugely different, and it doesn't make sense for us to spend a lot
of time getting one variant working, and then deciding that we need to
switch to the other one.
Cheers,
Ehsan
Ehsan Akhgari
> I know that Ehsan has already been thinking about how we could manage
> separate session cookies in a single process; I don't know how far along
> that process is currently, but I think we could prioritize and fix it
> fairly quickly.
So, the stuff that I have in my head related to this is mostly coming
from plans to implement a per-window private browsing implementation.
The general idea is to store a private browsing flag on the docshell,
and then propagate the PB flag from the docshell to the callsites which
need to make a choice on whether they want to store something on the
disk or not.
We can apply the same idea in order to get separate session cookies in a
single process. We should just store a session ID of some sort in the
docshell, and ask the cookie service to store/retrieve cookies for that
session when we're making an HTTP request. So in short, this is
possible to support fairly easily if we need it.
Cheers,
Ehsan
Mike Hanson
> As Ted says, there's a lot of overlap here with what WebRunner does today. Getting the native shells to work on all platforms was a non-trivial effort so it might make sense to look at the code that's there (which is all MPL and originated in Mozilla Labs). To your specific points:
Hi, Matt - the WebRunner/Prism project is an inspiration for this work. I was definitely hoping to reuse some of your great work on it.
Responding to a couple points as they came across threads:
On Aug 3, 2011, at 7:12 AM, Matthew Gertner wrote:
>
> On Wed, Aug 3, 2011 at 4:20 PM, Benjamin Smedberg <benj...@smedbergs.us> wrote:
> I believe that the common use case will be to start visiting a site in the browser. Maybe if it's nice, you will pin it as an app tab, and eventually decide to push into its own window. Maybe you'll decide you don't want it in a separate window and move it back into an app tab. If you have to start over with a separate local store and cache during the transition, that will be painful. This is especially true as we start to use the browser as an identity broker.
>
> Sure, I totally agree that people will tend to start in the browser and then spin off a separate app for certain sites. That's exactly what WebRunner does. To the extent that local store and cache are significant they can be copied over as I proposed before. It would be awesome if they were shared but simply copying the existing one into the app is probably a good 80/20 solution.
> <snip>
> It would be awesome to have the ability to share profiles wholly or partially between different Firefox instances, and as Mike says, this has been discussed and written about at length. But this is an orthogonal issue to the question of how to architect the native shells. Since there is a working solution based on Mozilla technologies that originated inside Mozilla and has a few years of history in the world, wouldn't it make sense to use that as a starting point? Stuff like shared profiles and lightweight content-rendering processes can be taken advantage of once they are implemented.
>
> This certainly doesn't mean WebRunner couldn't be improved in many ways of course!
There are two feature areas that are being kicked around that might speak to the need for data synchronization - one is identity management, and the other, which is related, is support for a "web receipt" to support opt-in application payment infrastructure. Our current BrowserID proposal depends on client-side private keys, which will eventually be stashed into profile-local storage. It would be annoying - and break the "appiness" - if the user had to present his or her credentials again when the launched an app. Similarly, a collection of "web receipts" - which key the user's purchases to one or more of the BrowserID identities - should be stored in a secure local place, and available to all apps.
Perhaps, rather than solving the general purpose profile sharing problem, which could become very detailed, a series of smaller solutions to specific problems could be made. (Which is, I think, where Ehsan's suggestion was headed).
>
> On OSes that support multi-window document-oriented applications, it
> would be nice to let the application interact with application-level
> events. How should application-level events like "open this
> document", "make a new document" or "quit now" be exposed? How could
> system level navigation APIs like the Task Bar's "jump lists" and the
> Docks's "command shortcuts" be exposed? How about interactions with
> OS-level content-type handler APIs?
>
> If you make Firefox your runtime you don't have to worry about this. Again, since it's a real app you can you normal OS APIs to create content handlers (WebRunner has APIs for this on Windows, Mac and Linux).
Yes, as far as the OS glue goes - but we still need to define how those events appear in the context of the web application. If you have a traditional web application whose context is scoped at "window", you don't have a way to iterate through all the windows. I was wondering if we need an "app.js" somewhere which has message handlers for all those events - if not, it's going to be complicated and contention-prone to handle it in windows. (This is a problem that complicated web apps have today, when dealing with cross-tab dependencies; the Chrome team has proposed some sort of window.frames property to allow application windows to talk directly to each other).
m
Matthew Gertner
>
> As Benjamin mentioned, this is something that we need to answer first
> before delving into the technical sides of it. Depending on which behavior
> we want, the technical requirements to realize them are going to be hugely
> different, and it doesn't make sense for us to spend a lot of time getting
> one variant working, and then deciding that we need to switch to the other
> one.
>
>
Aren't there really two issues here? One is whether to share some or all of
the profile between apps. I don't really see why this has such a huge impact
on the technical requirements. It seems to me like this is something that
can be worked on and improved incrementally and independent of a native
content shell implementation for web apps.
The other issue is whether to implement the native shells as fully-blown
Firefox instances or lightweight content shells that just render content
from a single main process (i.e. what Chrome does and what I assume
electrolysis is aiming to do). I don't think this has anything to do with
whether profiles are shared or not (in fact there are compelling reasons to
have separate profiles even if there is only one main Firefox process).
Having a lot of separate Firefox instances does use up a lot of memory
though. If there were some way to lessen this by having lightweight content
shells then that would be a big win.
Is this something you would get more or less "for free" when electrolysis is
completed? In other words, would native shells just be like an other browser
window but with some additional desktop app UI around them (e.g. dock icon,
separate Windows menu, etc.)? Does that mean that you will wait until
electrolysis is deployed before implementing native shells? What timeframe
do you expect that to happen in?
Matt
Matthew Gertner
> There are two feature areas that are being kicked around that might speak
> to the need for data synchronization - one is identity management, and the
> other, which is related, is support for a "web receipt" to support opt-in
> application payment infrastructure. Our current BrowserID proposal depends
> on client-side private keys, which will eventually be stashed into
> profile-local storage. It would be annoying - and break the "appiness" - if
> the user had to present his or her credentials again when the launched an
> app. Similarly, a collection of "web receipts" - which key the user's
> purchases to one or more of the BrowserID identities - should be stored in a
> secure local place, and available to all apps.
>
> Perhaps, rather than solving the general purpose profile sharing problem,
> which could become very detailed, a series of smaller solutions to specific
> problems could be made. (Which is, I think, where Ehsan's suggestion was
> headed).
>
You nailed it. The notion of a "browser profile" is becoming obsolete.
Instead, there is a set of app-specific data (whether the app is a normal
tab, an app tab or a separate app in a native shell) and a set of global
browser data. Where to draw the line is a matter of conjecture at this
point. Maybe we want global prefs and app-specific prefs, global extensions
and app-specific extensions, etc. I do know that people value the ability to
associate different WebRunner apps with different identities so it isn't a
no-brainer that all apps should share even the same BrowserID.
This can get very complex and relies on a lot of guesses about user
preferences. If it were me, I would start with a nice simple implementation
based on separate profiles and tackle the issue of sharing data between
profiles separately and incrementally. This will speed time-to-market and
make sure that decisions are based on real feedback from users.
>
>
> Yes, as far as the OS glue goes - but we still need to define how those
> events appear in the context of the web application. If you have a
> traditional web application whose context is scoped at "window", you don't
> have a way to iterate through all the windows. I was wondering if we need
> an "app.js" somewhere which has message handlers for all those events - if
> not, it's going to be complicated and contention-prone to handle it in
> windows. (This is a problem that complicated web apps have today, when
> dealing with cross-tab dependencies; the Chrome team has proposed some sort
> of window.frames property to allow application windows to talk directly to
> each other).
>
>
You presumably going to want a bunch of app APIs for things like registering
an app to handle a certain content type, badging the app's dock icon, etc.
(basically what we have in our "webrunner" JS global property). An API for
coordinating between windows could hang off that.
Matt
Benjamin Smedberg
>
> The other issue is whether to implement the native shells as
> fully-blown Firefox instances or lightweight content shells that just
> render content from a single main process (i.e. what Chrome does and
> what I assume electrolysis is aiming to do). I don't think this has
> anything to do with whether profiles are shared or not (in fact there
> are compelling reasons to have separate profiles even if there is only
> one main Firefox process). Having a lot of separate Firefox instances
> does use up a lot of memory though. If there were some way to lessen
> this by having lightweight content shells then that would be a big win.
>
> Is this something you would get more or less "for free" when
> electrolysis is completed? In other words, would native shells just be
> like an other browser window but with some additional desktop app UI
> around them (e.g. dock icon, separate Windows menu, etc.)? Does that
> mean that you will wait until electrolysis is deployed before
> implementing native shells? What timeframe do you expect that to
> happen in?
relatively simply right now (on Windows/Linux, as I noted up front). You
just hook up a child window owned by the Firefox process and away you
go. This doesn't depend on content processes at all.
"sharing" profiles is a large engineering task which we've tried at
least twice before and mostly failed. Running with multiple 'profiles'
in a single instance is also a large engineering task which we might
want to take on (or at least partly), but I don't think either of these
need to block getting apps working.
I think of webrunner as a cool labs experiment which has been useful to
a subset of power users, but not the right technology to put into
production. We really want to share a bunch of stuff between Firefox and
apps right off the bat, including cache, identity management, and
extension. Implementing this in a single process to start will provide
the quickest path forward and we won't have to deal with a host of
engineering issue to deal with whatever subset of sharing we decide is
necessary for round one.
--BDS
Matthew Gertner
> This really isn't related to electrolysis and is something we can do
> relatively simply right now (on Windows/Linux, as I noted up front). You
> just hook up a child window owned by the Firefox process and away you go.
> This doesn't depend on content processes at all.
>
> "sharing" profiles is a large engineering task which we've tried at least
> twice before and mostly failed. Running with multiple 'profiles' in a single
> instance is also a large engineering task which we might want to take on (or
> at least partly), but I don't think either of these need to block getting
> apps working.
>
> I think of webrunner as a cool labs experiment which has been useful to a
> subset of power users, but not the right technology to put into production.
> We really want to share a bunch of stuff between Firefox and apps right off
> the bat, including cache, identity management, and extension. Implementing
> this in a single process to start will provide the quickest path forward and
> we won't have to deal with a host of engineering issue to deal with whatever
> subset of sharing we decide is necessary for round one.
>
So the app wouldn't get its own icon in the taskbar or dock? How is a
"native shell" different from just running the app in a separate browser
window in that case?
Matt
Benjamin Smedberg
>
>
> So the app wouldn't get its own icon in the taskbar or dock? How is a
> "native shell" different from just running the app in a separate
> browser window in that case?
--BDS
Ehsan Akhgari
> On Wed, Aug 3, 2011 at 11:59 PM, Mike Hanson<mha...@mozilla.com> wrote:
>
>> There are two feature areas that are being kicked around that might speak
>> to the need for data synchronization - one is identity management, and the
>> other, which is related, is support for a "web receipt" to support opt-in
>> application payment infrastructure. Our current BrowserID proposal depends
>> on client-side private keys, which will eventually be stashed into
>> profile-local storage. It would be annoying - and break the "appiness" - if
>> the user had to present his or her credentials again when the launched an
>> app. Similarly, a collection of "web receipts" - which key the user's
>> purchases to one or more of the BrowserID identities - should be stored in a
>> secure local place, and available to all apps.
>>
>> Perhaps, rather than solving the general purpose profile sharing problem,
>> which could become very detailed, a series of smaller solutions to specific
>> problems could be made. (Which is, I think, where Ehsan's suggestion was
>> headed).
>>
>
> You nailed it. The notion of a "browser profile" is becoming obsolete.
> Instead, there is a set of app-specific data (whether the app is a normal
> tab, an app tab or a separate app in a native shell) and a set of global
> browser data. Where to draw the line is a matter of conjecture at this
> point. Maybe we want global prefs and app-specific prefs, global extensions
> and app-specific extensions, etc. I do know that people value the ability to
> associate different WebRunner apps with different identities so it isn't a
> no-brainer that all apps should share even the same BrowserID.
I still think that the technical solution should not come first. If we
decide that we want each app to run in its own isolated environment, and
only ever share a few pieces of information with other app/Firefox
instances, then separate profiles would be the way to go. If, however,
we decide that we want apps to share commonly used profile information
such as history/bookmarks, saved passwords, identity information, etc,
the best technical solution would be what Benjamin and I have been
suggesting.
> This can get very complex and relies on a lot of guesses about user
> preferences. If it were me, I would start with a nice simple implementation
> based on separate profiles and tackle the issue of sharing data between
> profiles separately and incrementally. This will speed time-to-market and
> make sure that decisions are based on real feedback from users.
As Benjamin said, profile sharing implementation would be a huge
engineering effort. So, if we start basing our implementation on
separate profiles, and then later on decide that what we really want is
shared data across app/Firefox instances, then we would either have to
start from scratch using the shared process/profile approach, or go
through the pain of implementing profile sharing, and getting it right,
in which case we end up slowing down shipping this to our users.
Cheers,
Ehsan
willia...@gmail.com
I don't know what I'm going to do now to handle multiple Google account without constantly switching. (sad face)
Ehsan Akhgari
at the all-hands?
Thanks!
--
Ehsan
<http://ehsanakhgari.org/>
Mike Hanson
For Q4, we're committing to fixing WebRunner (or its spiritual equivalent), and adding two features: integrating it with an app manifest that includes a "capabilities" request list, which would act as an upper bound for what permissions WebAPI would grant, and supporting a DOM API for installation requests (which would allow the calling page to attach some metadata to the install, e.g. an identity token or receipt).
I've also written up a specification for what would be different in a "shared-runtime" web platform, here:
https://wiki.mozilla.org/Apps/WebRT
The goal of that spec is not to indicate "how", but to be clear about "what". Feedback on that is especially welcome, here or on the discuss page of the wiki.
-M
David Rajchenbach-Teller
cookies are not shared between apps, which sounds like the right thing
to do.
However, if I understand correctly, the cache seems to be shared
between apps. There are a number of ways to implement cookie-like
features using only the cache, or the cache + JavaScript. Do I
understand correctly that solving this is not a priority for the first
version?
Best regards,
David
willia...@gmail.com
David Rajchenbach-Teller
Hash: SHA1
On 10/6/11 10:01 PM, Mike Hanson wrote:
> There has, yes.
>
> For Q4, we're committing to fixing WebRunner (or its spiritual
> equivalent), and adding two features: integrating it with an app
> manifest that includes a "capabilities" request list, which would
> act as an upper bound for what permissions WebAPI would grant, and
> supporting a DOM API for installation requests (which would allow
> the calling page to attach some metadata to the install, e.g. an
> identity token or receipt).
>
> I've also written up a specification for what would be different in
> a "shared-runtime" web platform, here:
> https://wiki.mozilla.org/Apps/WebRT
>
> The goal of that spec is not to indicate "how", but to be clear
> about "what". Feedback on that is especially welcome, here or on
> the discuss page of the wiki.
>
> -M
>
objectives of WebRT would be sufficient to obtain a non-disruptive
form Private Browsing, i.e. essentially spawn a new WebRT + address
bar for each request for Private Browsing.
Could be nice to get those to birds with one stone.
Cheers,
David
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOkZC6AAoJED+FkPgNe9W+drkH/jaalAJBmcrjo5dMssWkWdzr
YP1GwZbBqh6MFB9v/MMYT6lDcy7SfOJEKwSV8zmyUl2mdaamQiLXIlc49EqNZywI
3GzQgQM0KdyD4tD3zpqXlEZmo0D6rP6EaCCU1uIi8onq3f3j1+HdsQ0Ir6njWtbH
0mLQ9RhgZ3AwsU0YbWP6jniJ9kwq3/yW9hyLHhnyz4/cS9fdVq6wjh7EcziLDEQs
zeQ7hDGibyRo7QarXSmjuhbVfOS1qaXKTHtrUso+29XXK1hh35BMwr9HtV7694Yw
vKiNmk+Spvo4OCB1UjYqISqZ/H+mmqQvVsiOpWWiYkzm1sTvBlGg6nngB93MGfM=
=NDeK
-----END PGP SIGNATURE-----
Ehsan Akhgari
> There has, yes.
>
> For Q4, we're committing to fixing WebRunner (or its spiritual equivalent),
> and adding two features: integrating it with an app manifest that includes a
> "capabilities" request list, which would act as an upper bound for what
> permissions WebAPI would grant, and supporting a DOM API for installation
> requests (which would allow the calling page to attach some metadata to the
> install, e.g. an identity token or receipt).
>
> I've also written up a specification for what would be different in a
> "shared-runtime" web platform, here:
> https://wiki.mozilla.org/Apps/WebRT
>
> The goal of that spec is not to indicate "how", but to be clear about
> "what". Feedback on that is especially welcome, here or on the discuss page
> of the wiki.
>
I'm mostly interested in the details of how you're planning to share profile
information between different apps. Are you looking to run all apps in the
same Firefox process (or maybe content processes) and prevent sharing of
specific data such as cookies in the apps, or are you looking to run each
app in its own profile and share the data in the profile between all of the
applications?
Reuben Morais
> I don't know what I'm going to do now to handle multiple Google account without constantly switching. (sad face)
>
being worked on:
https://www.google.com/support/accounts/bin/answer.py?answer=181599
(Sorry if this gets sent twice, gmail said the first email didn't get there)
--
Reuben
Benjamin Smedberg
> There has, yes.
>
> For Q4, we're committing to fixing WebRunner (or its spiritual equivalent), and adding two features: integrating it with an app manifest that includes a "capabilities" request list, which would act as an upper bound for what permissions WebAPI would grant, and supporting a DOM API for installation requests (which would allow the calling page to attach some metadata to the install, e.g. an identity token or receipt).
>
> I've also written up a specification for what would be different in a "shared-runtime" web platform, here:
> https://wiki.mozilla.org/Apps/WebRT
>
> The goal of that spec is not to indicate "how", but to be clear about "what". Feedback on that is especially welcome, here or on the discuss page of the wiki.
do it?
As previously discussed, I still object pretty strongly to having
separate browing history for apps: it makes apps such as google reader
and gmail much less useful to me (because link coloring for visited
links doesn't work). What is the *benefit* we get from separate history
stores?
Cookies are not mentioned in the spec, and are a fundamental issue that
needs to be addressed. Again I think we should start or default to
completely shared cookies, and deal with the identity/multiple signon
issues as a later step.
Is the "domain capture" logic the full domain, or TLD+1? There really
needs to be a way for web apps to override the default behavior, since
there are plenty of ways in which you might want cooperating websites to
live in the same "app UI".
Also not mentioned are addons: how will addons be allowed modify app
behavior? Will there be UI hooks specifically designed into jetpack (or
will the existing UI hooks in the SDK be made to work for apps)?
I don't understand what section 9.2 has to do with webapps or this spec
at all. At least as originally filed, bug 299989 wasn't about webapps at
all, and we've already decided that we're not "productizing" XULRunner
as it is.
From an engineering & QA perspective, it would be a lot better to just
ship one set of bits which runs Firefox and webapps. If it really is a
product decision that we don't want to appear to have installed Firefox
on the system, we should hide the Firefox icons and just have the
marketplace icons, but it would still be all the same thing. The fewer
different pieces of code we have to manage in terms of update streams,
downloads, and possibly funky interactions, the better.
I don't really understand the limitations of Android in terms of user
data and .apk yet: is there a good page describing how apps can interact
or use data, or can somebody who knows this really well give a braindump?
--BDS
David Rajchenbach-Teller
Hash: SHA1
I will need to read again that spec because I understood something
quite different. Still, I personally see great value in separating
cookies and identity between applications, for privacy reasons: I
would rather avoid giving away to, say, Facebook, the fact that I am
the same person using these three distinct applications who all happen
to have a "like" button.
On the other hand, I +1 Benjamin's questions. Pun intended.
Best regards,
David
> _______________________________________________ dev-platform
> mailing list dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOkxgeAAoJED+FkPgNe9W+gGMIALGOUffJFiN8XaT498vWrkuJ
HBUb2LnqM5ae5iU+djVPoppAepmu5NnF6v+kflUKsURhQnfZ3JC5dOk0EjwXGum9
pqZ/pXQHh+LojZpYFusfCmBbPe1ipO7dIIDQev8Hs67gKEOQscjvnSdlhy6zUpu0
xyx9QYHrlOxRew742jK1v6eGTx647l14X5GsZ0ysd3biONKoeDXFG3WgtcTqSieJ
hNLZ+VLO2l/zqW+u/NQMx/3ImsDP8YsMAAi1nYySCHh2nPn0dd3G+gJXfGcwkhr0
v+m4sIz7zPUBJYjX4u/MfdZpnQoFi7hQ/xZgJJWpPXyO7reVpeIMNPsfHzXEaqg=
=SZks
-----END PGP SIGNATURE-----
Mchl
> FWIW, I'm a webrunner user and I use (well, used, as it's now broken) it for exactly the use cases Matt described. I ran my Google Apps as one webrunner app and my Gmail/Google+ as a separate webrunner app, both separate from my browser. For this, I needed separate profiles, separate cookies, and it was very useful to have separate extensions in each, as this gave me greasemonkey-like customization of Google Apps with better performance. I could care less about bookmarks as I do all my browsing in my Firefox instance. The most important thing for me was that they're separate profiles that don't talk to one another. Memory consumption was of little importance, more important was that they had their own icon, could be associated with actions like clicking on mailto: links, etc.
>
> I don't know what I'm going to do now to handle multiple Google account without constantly switching. (sad face)
similar requirements. We use Prism/Webrunner for our intranet web
application, and having it isolated from web browser is pretty
important. One argument not mentioned so far is the ability to set up
different firewall rules for browser, and different for Webrunner.