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:
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!
As someone noted in the meeting yesterday, this is all very similar to 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?
> 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.
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.
>> 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?
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: matt...@salsitasoft.com – Mobile: +420 603507882 – Skype: matthewgertner
> 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?
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.
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.
On Wed, Aug 3, 2011 at 4:20 PM, Benjamin Smedberg <benja...@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.
> 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!
>> 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.
> 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.
On Aug 3, 2011, at 7:12 AM, Matthew Gertner wrote:
> 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 <benja...@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).
On Wed, Aug 3, 2011 at 7:51 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com>wrote:
> 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?
On Wed, Aug 3, 2011 at 11:59 PM, Mike Hanson <mhan...@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.
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.
> 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?
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.
> 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?
> 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?
> On Wed, Aug 3, 2011 at 11:59 PM, Mike Hanson<mhan...@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.
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)
>> On Wed, Aug 3, 2011 at 11:59 PM, Mike Hanson<mhan...@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.
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.
> On Thu, Aug 4, 2011 at 11:18 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com> wrote:
> On 11-08-04 5:05 AM, Matthew Gertner wrote:
> On Wed, Aug 3, 2011 at 11:59 PM, Mike Hanson<mhan...@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.
I don't see anything about cookies in the wiki, so I assume that 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?
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)
> 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
Two more cents: reading the wiki, I realize that a subset of the
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/
On Thu, Oct 6, 2011 at 4:01 PM, Mike Hanson <mhan...@mozilla.com> 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.
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?
On Thu, Oct 6, 2011 at 2:58 PM, <william.g...@gmail.com> wrote:
> I don't know what I'm going to do now to handle multiple Google account without constantly switching. (sad face)
> 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.
Who is responsible for figuring out "what", and when are they going to 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?
