Re: [b2g] Nightly OTA update on Flame stops?
From the gaia meeting notes: ** OTA is busted due to https://bugzilla.mozilla.org/show_bug.cgi?id=1161579#c4 *** we need a forward fix, aus working on the issue. We still do create on the pvtbuild/ftp server, there's also builds on task cluster. Regards, Naoki On May 5, 2015, at 8:16 PM, Kan-Ru Chen (陳侃如) kc...@mozilla.com wrote: I haven't seen any updates on my Flame (update channel nightly) since 5/3 (build identifier 20150503160200). Looks like we still produce builds in http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/latest-mozilla-central-flame-kk/ Has anyone also had this issue? Kanru ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
[b2g] Nightly OTA update on Flame stops?
I haven't seen any updates on my Flame (update channel nightly) since 5/3 (build identifier 20150503160200). Looks like we still produce builds in http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/latest-mozilla-central-flame-kk/ Has anyone also had this issue? Kanru ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Aligning on an App Model for the future
While I’m all for simplification, installation is a useful metaphor for signalling user intent. Removing installation leaves us limited to prompts only. Prompts are pretty limited in terms of a security mitigation and we will have a hard time authorising access to the privileged APIs, especially (but not only) those which are currently granted without user consent (implicit permissions). And we are not talking at all here about extensions/add-ons which afaik is a key part of ignite. I think there is a still case for install, especially for “add-on” content. So I imagine something more like this: Content (linkable, no install required) Web Content Web Apps Signed Web Apps (for APIs with prompt only) Add-ons (not linkable? installed via install step) Signed Web Apps (apps that need access to more sensitive or implicit APIs, or things we generate with customiser etc) - Paul On 5 May 2015, at 7:06 am, Jonas Sicking jo...@sicking.cc wrote: Hi Peter, I think we can and should simplify this actually. The main thing that I think we should do is abandon the term app. The term app is often associated with things like installing and app store, both of which I'd like to move away from. To be clear, I think we should still have our marketplace. But not as the sole provider of install buttons as it is today. But rather as a directory of content works really well on FirefoxOS, similar to the dmoz.org of days past. But I think we generally should just consider web content as web content. I.e. as normal websites that you can browse to. Having a W3C or a FirefoxOS manifest shouldn't really make a big difference in what that content can do, what permission it gets or what UI it has. I think this should be the basis for our design. That content is just content. Especially from a user perspective having just a single type of content is the simplest thing. There are a couple of complexities though. The first one is what we currently call privileged apps. I.e. pages that get access to additional APIs, like TCPSocket and DeviceStorage. From a user perspective I think we should still simply treat this as web content. I.e. it's something that you can browse to in the browser and without requiring any installation. However from a security point of view we'll still need this content to go through a marketplace review and get signed. I think we should refer to this content as signed content. I.e. web pages that have been authorized by the marketplace team to get access to additional APIs, and which is signed by the marketplace. More details about the current proposal for how to deliver that content and that signature is available in [1], though there are a couple of alternative proposals that we're still investigating. But from a user point of view, signed content still acts and behaves just like normal web content. So mainly signed content is an implementation complexity which hopefully won't affect the user or UX. But I do think that this signing mechanism is something we need to call out in your document because it does affect web developers. Specifically it affects developers which need access to sensitive APIs as described by [1]. The second complexity is pinning. I think we should allow users to pin websites to the homescreen. This should be possible for *any* website, whether it has a W3C manifest, a FirefoxOS manifest, the Apple-invented meta tags, or none of the above. When the user pins a website I think we should grant it some additional permissions automatically. Mainly we should grant it the ability to store more data, run in the background using the BackgroundSync and Alarm APIs and maybe create notifications. It might also give that content special UX treatments, such as the ability to show up in webactivity picker, or to run without a URL bar. But all those capabilities should come with getting pinned. It should not be related to if the website has any types of manifests or not. Additionally, ideally the capabilities, like storage, BackgroundSync API, Alarm API and notification API, is something that we make available to all websites. However if the user hasn't pinned the website the user would get prompted. So really the pinning is mainly about UX. I.e. the prompting UX disappear, and the website can choose to hide URL bar or appear in the webactivity picker. Given that web developers care a lot about UX, I do think that the pinning aspect is also worth mentioning in your document. [1] https://wiki.mozilla.org/FirefoxOS/New_security_model / Jonas On Thu, Apr 16, 2015 at 12:27 PM, Peter Dolanjski pdolanj...@mozilla.com wrote: Hello All, There have been a number of discussion threads around the details pertaining to the various forms of apps that are needed as we move forward with new architecture (based on permissions, presence of a manifest, etc.). A few of us (product, engineering, partner
Re: [b2g] Aligning on an App Model for the future
Jonas Sicking mailto:jo...@sicking.cc May 4, 2015 at 5:06 PM Hi Peter, I think we can and should simplify this actually. The main thing that I think we should do is abandon the term app. The term app is often associated with things like installing and app store, both of which I'd like to move away from. To be clear, I think we should still have our marketplace. But not as the sole provider of install buttons as it is today. But rather as a directory of content works really well on FirefoxOS, similar to the dmoz.org of days past. But I think we generally should just consider web content as web content. I.e. as normal websites that you can browse to. Having a W3C or a FirefoxOS manifest shouldn't really make a big difference in what that content can do, what permission it gets or what UI it has. I think this should be the basis for our design. That content is just content. Especially from a user perspective having just a single type of content is the simplest thing. There are a couple of complexities though. The first one is what we currently call privileged apps. I.e. pages that get access to additional APIs, like TCPSocket and DeviceStorage. From a user perspective I think we should still simply treat this as web content. I.e. it's something that you can browse to in the browser and without requiring any installation. However from a security point of view we'll still need this content to go through a marketplace review and get signed. I think we should refer to this content as signed content. I.e. web pages that have been authorized by the marketplace team to get access to additional APIs, and which is signed by the marketplace. More details about the current proposal for how to deliver that content and that signature is available in [1], though there are a couple of alternative proposals that we're still investigating. But from a user point of view, signed content still acts and behaves just like normal web content. So mainly signed content is an implementation complexity which hopefully won't affect the user or UX. But I do think that this signing mechanism is something we need to call out in your document because it does affect web developers. Specifically it affects developers which need access to sensitive APIs as described by [1]. The second complexity is pinning. I think we should allow users to pin websites to the homescreen. This should be possible for *any* website, whether it has a W3C manifest, a FirefoxOS manifest, the Apple-invented meta tags, or none of the above. When the user pins a website I think we should grant it some additional permissions automatically. Mainly we should grant it the ability to store more data, run in the background using the BackgroundSync and Alarm APIs and maybe create notifications. It might also give that content special UX treatments, such as the ability to show up in webactivity picker, or to run without a URL bar. But all those capabilities should come with getting pinned. It should not be related to if the website has any types of manifests or not. Additionally, ideally the capabilities, like storage, BackgroundSync API, Alarm API and notification API, is something that we make available to all websites. However if the user hasn't pinned the website the user would get prompted. So really the pinning is mainly about UX. I.e. the prompting UX disappear, and the website can choose to hide URL bar or appear in the webactivity picker. Given that web developers care a lot about UX, I do think that the pinning aspect is also worth mentioning in your document. [1] https://wiki.mozilla.org/FirefoxOS/New_security_model / Jonas On Thu, Apr 16, 2015 at 12:27 PM, Peter Dolanjski ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g Peter Dolanjski mailto:pdolanj...@mozilla.com April 16, 2015 at 3:27 PM Hello All, There have been a number of discussion threads around the details pertaining to the various forms of apps that are needed as we move forward with new architecture (based on permissions, presence of a manifest, etc.). A few of us (product, engineering, partner engineering, Marketplace) got together to try to assemble a simple description of what each distinct category is for and when they would be used. I plan to publish this on one of the v3 wikis, but before I do I just wanted to open it up for comments/suggestions. You can see the breakdown here: v3 App Model https://docs.google.com/a/mozilla.com/document/d/1_OFzh9P-2jjf_iqtgd_9qNfgkoquo3nBt9oE3XVPRZw/edit Feel free to comment right in the doc. In addition, I'll summarize it here in case you prefer some email dialogue on it: *_Web Site_* Description: Vanilla web site with no app manifest. Distribution Channel(s): 1. Any web server 2. Indexed by Marketplace (hosted elsewhere) Why would a Developer choose this option? - Just a web site that should be used inside the browser. (no point in
Re: [b2g] Exposing the browser api reference to the internal/certified apps(eg. System app) themselves?
We did talk about these solutions and neither is desirable as they adds significant complexity to the System app internal, and the cost of reviewing every future patch. (We even went to not-so-crazy ideas like simply overwrite window.Audio with our wrap) That's why a platform API is better and uniform IMHO. On Tue, May 5, 2015 at 4:24 AM, Jonas Sicking jo...@sicking.cc wrote: Technically the system app *can* manage its own sound. By using .volume and .pause()/.play() functions on the audio elements directly. I understand that it adds extra complexity to the code to manage all other audio using the Browser API, but the system app audio using the audio API. One potential solution here would be to write a JS library which wraps both the audio API and the Browser API and exposes the same API for managing both. That might be less work than adding more platform APIs here? / Jonas On Mon, May 4, 2015 at 2:31 AM, Dominic Kuo d...@mozilla.com wrote: Hi folks, Recently, some of the b2g folks are refactoring the audio channel service in [1], what we do is using the new broswer api [2] to allow/deny the audio channels, then wrap up those logic we used in gecko then re-implement it in gaia. It's a sub-module [3] directly in the System app, in theory it's capable of managing any iframe/app's audio channel which created under the System app. The problem we encountered is, we use some audio elements to play sounds in the System app, like the notification, screen reader, ringtones..., this means we also need to manage the System app's audio channels. The trivial way is to do it in its parent(shell.js), it can be done but imagine that, there will be duplicate/extra logic to manage the System app's audio channels, just like those we implemented for all the gaia apps and seems strange for us. So we are wondering that, does it make sense to expose the browser api reference to the System app itself? so that the the System app is able to manipulate its own browser api then manage its audio channels. Reason: the System app is unable to manage its own audio channels. (if we don't do it in shell.js) Proposal: the internal/certified app has some way to access the browser api then manipulate them. (Possibly in the future there might be some similar usages, the System app needs its browser api to manage things.) Any thoughts? (We are also discussing the alternative solution in [4] and feel free to give us some idea!) [1] Refactor Audio Channel Service: https://bugzilla.mozilla.org/show_bug.cgi?id=1089539 [2] Audio Channel Browser api: https://bugzilla.mozilla.org/show_bug.cgi?id=1113086 [3] Audio Channel Service: https://bugzilla.mozilla.org/show_bug.cgi?id=1100822 [4] Manage the System app's audio channels: https://bugzilla.mozilla.org/show_bug.cgi?id=1157140 Thanks, - Dominic ___ dev-webapi mailing list dev-web...@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-webapi ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Aligning on an App Model for the future
Thanks Jonas/Eric. Excellent points. Let me engage some folks on our UX team to get their input and we'll summarize that on this thread. A big thing that we need to grapple with are user expectations and perceptions with respect to apps. Obviously we want to advance the technology and change the current perception that the Web is incapable of some of the experiences that apps provide, but we also need to deal with the reality in the market that no apps = a product death sentence. We witnessed that when a shop keeper in New Delhi sells a device, the sales pitch is roughly this device has all the apps you need so you can't go wrong buying this Android smartphone vs. this device doesn't have any apps, so you definitely don't want this unless you're just making phone calls. My point is, there is an experience and positioning line we'll need to straddle to get this right. Peter On Tue, May 5, 2015 at 2:05 AM, Eric Shepherd esheph...@mozilla.com wrote: Jonas Sicking jo...@sicking.cc May 4, 2015 at 5:06 PM Hi Peter, I think we can and should simplify this actually. The main thing that I think we should do is abandon the term app. The term app is often associated with things like installing and app store, both of which I'd like to move away from. To be clear, I think we should still have our marketplace. But not as the sole provider of install buttons as it is today. But rather as a directory of content works really well on FirefoxOS, similar to the dmoz.org of days past. But I think we generally should just consider web content as web content. I.e. as normal websites that you can browse to. Having a W3C or a FirefoxOS manifest shouldn't really make a big difference in what that content can do, what permission it gets or what UI it has. I think this should be the basis for our design. That content is just content. Especially from a user perspective having just a single type of content is the simplest thing. There are a couple of complexities though. The first one is what we currently call privileged apps. I.e. pages that get access to additional APIs, like TCPSocket and DeviceStorage. From a user perspective I think we should still simply treat this as web content. I.e. it's something that you can browse to in the browser and without requiring any installation. However from a security point of view we'll still need this content to go through a marketplace review and get signed. I think we should refer to this content as signed content. I.e. web pages that have been authorized by the marketplace team to get access to additional APIs, and which is signed by the marketplace. More details about the current proposal for how to deliver that content and that signature is available in [1], though there are a couple of alternative proposals that we're still investigating. But from a user point of view, signed content still acts and behaves just like normal web content. So mainly signed content is an implementation complexity which hopefully won't affect the user or UX. But I do think that this signing mechanism is something we need to call out in your document because it does affect web developers. Specifically it affects developers which need access to sensitive APIs as described by [1]. The second complexity is pinning. I think we should allow users to pin websites to the homescreen. This should be possible for *any* website, whether it has a W3C manifest, a FirefoxOS manifest, the Apple-invented meta tags, or none of the above. When the user pins a website I think we should grant it some additional permissions automatically. Mainly we should grant it the ability to store more data, run in the background using the BackgroundSync and Alarm APIs and maybe create notifications. It might also give that content special UX treatments, such as the ability to show up in webactivity picker, or to run without a URL bar. But all those capabilities should come with getting pinned. It should not be related to if the website has any types of manifests or not. Additionally, ideally the capabilities, like storage, BackgroundSync API, Alarm API and notification API, is something that we make available to all websites. However if the user hasn't pinned the website the user would get prompted. So really the pinning is mainly about UX. I.e. the prompting UX disappear, and the website can choose to hide URL bar or appear in the webactivity picker. Given that web developers care a lot about UX, I do think that the pinning aspect is also worth mentioning in your document. [1] https://wiki.mozilla.org/FirefoxOS/New_security_model / Jonas On Thu, Apr 16, 2015 at 12:27 PM, Peter Dolanjski ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g Peter Dolanjski pdolanj...@mozilla.com April 16, 2015 at 3:27 PM Hello All, There have been a number of discussion
