On Tue, Mar 10, 2015 at 5:32 AM, Benjamin Francis <[email protected]> wrote:
>
> This sounds great, I fully agree. Comments inline.
>
> On 10 March 2015 at 00:23, Jonas Sicking <[email protected]> wrote:
>>
>> First off, I think we should get rid of "apps" as a platform feature.
>
> Let's unpack that a little.

https://www.youtube.com/watch?v=E3AjTqTwIdk

> What I don't necessarily think we should get rid of is the app registry.

I guess I don't have a strong opinion.

I do think that the registry can be simplified compared to what it is today.

What we basically need is a bookmark registry. Which maintains a list
of which pages/manifests that the user has bookmarked.

I'm absolutely not in a hurry to modify our registry code though. I'll
leave that up to the owners of that code.

I would imagine that exactly what we do will depend on various UX
decisions. Such as how to implement display modes.

>> * Enable the user to simply navigate to content which uses sensitive
>> APIs, without the need to install it first. I.e. enable the content to
>> be available through "real" linkable URLs.
>
> Agreed. Ideally web apps should work equally well inside and outside the 
> browser.
>
> One thing I don't think we want (though this is largely a UX issue) is for a 
> browser window to constantly switch between different display modes as you 
> simply browser non-installed web apps, i.e. a manifest shouldn't be applied 
> to a browsing context simply by navigating to a URL if the app that manifest 
> describes has not been installed/pinned. This could make for a very 
> nauseating experience if the display mode keeps changing as you browse, and 
> provides a vector for phishing attacks if any web content can enter a 
> standalone display mode without an explicit user action.
>
> My opinion is that the browser chrome provides the user with a safety net 
> while they browse web sites and web apps (they always know where they are, 
> and can always go back), the manifest should only be applied when the user is 
> no longer "just browsing" but has installed/pinned the app to their device. 
> From that point on that app should handle its own URL scope in its preferred 
> display mode and can capture navigations to those URLs so the system can 
> switch to an app window to handle a navigation.
>
> Maybe a creative UX designer can re-invent browser chrome and provide a UI 
> where the installation step is not necessary, but I haven't yet seen a design 
> which achieves that.

Indeed. I think we need to get more UX input on this stuff.

>> * While I think signed content that can use sensitive APIs should have
>> real URLs, I think it needs to never be same-origin with unsigned
>> "normal" content.
>
> This makes sense from a security point of view, a challenge is going to be 
> that for a signed hosted resource to talk to other resources on its own 
> domain (like a server-side API), it will need to have CORS set up (otherwise 
> something like systemXHR is needed). The obvious answer is to encourage 
> developers to use CORS, but that can be a hard pill to swallow. How do you 
> even configure CORS to give access to its own domain...?

Yes, this is a good point. I don't think we'll want to force
developers to use CORS to talk to their own server.

>> The only content distinction we'd end up with is "signed" vs.
>> "unsigned". And to the user both would look like normal web.
>>
>> The "signed" content will be FirefoxOS specific until we find others
>> which are interested in collaborating on APIs, which isn't expected to
>> be soon. But to put this in perspective, the vast majority of authors
>> are able to author content without using these APIs.
>
> This isn't a technical issue, but I would suggest that we re-brand Firefox* 
> specific certified and privileged apps as "Firefox Apps", and hosted apps as 
> simply "Web Apps", and start to migrate those apps to use the new W3C 
> manifest format. the properties of the mozApps hosted app manifest could just 
> be proprietary extensions of the W3C manifest until that spec matures enough 
> to fulfil all use cases.

Yeah, I agree that we should make clear that signed content is Firefox-specific.

> We also need to provide an easy migration path for existing authors of 
> packaged apps. I would suggest this should include offering to host those 
> apps for people on a Mozilla-run or partner-run web server. Perhaps we can 
> talk to the Webmaker folks about that?

My hope is definitely to automatically convert packed apps on the
marketplace to whatever new formats we'll end up using.

/ Jonas
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g

Reply via email to