Closed Bug 1129625 Opened 9 years ago Closed 6 years ago

Only apply "Install" prefix to installable apps from Marketplace

Categories

(Firefox OS Graveyard :: Gaia::Search, defect)

Product:
Firefox OS Graveyard
Component:
Gaia::Search
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: pdol, Unassigned)

References

Details

(Whiteboard: [systemsfe]) 

Right now all apps found via the search API used by Rocketbar:
https://marketplace.firefox.com/api/v2/apps/search/rocketbar/?q={q}&limit={limit}
are prefixed with the word "Install" since all apps from Marketplace require installation.

In the event that Marketplace adds other forms of non-installable content (like websites) in the future, it would be ideal if they could be surfaced through the same Rocketbar experience, albeit without the "Install" prefix.  As such, Rocketbar should distinguish between those content types and only prefix "Install" if the content is, indeed, installable.

Bug 1129621 is to cover the API changes needed to support this.
If non-app results had a "url" instead of "manifest_url" (see bug 1129621) , would that break anything in previous versions of Firefox OS?
Shouldn't this be nominated for 2.2?
Flags: needinfo?(pdolanjski)
(In reply to Ben Francis [:benfrancis] from comment #1)
> If non-app results had a "url" instead of "manifest_url" (see bug 1129621) ,
> would that break anything in previous versions of Firefox OS?

Probably. If we make this change I assume we need to version the API. Right now we're using a 'v2' endpoint, I assume we would need to change to a 'v3' endpoint.
Check out bug 1129621 for an idea.  The proposal is just using 'url' instead of 'manifest_url' as a key.  If that's the case:

1) It's not a breaking change which means we wouldn't need to increment the API version

2) This bug wouldn't depend on the marketplace bug.  As long as it's looking for that key, we can finish the Marketplace API later.  This is an important point because the Marketplace only supports apps right now - not websites, which is still being scoped.
> 1) It's not a breaking change which means we wouldn't need to increment the API version

I can see a bunch of app.manifest_url calls directly in marketplace.js, guessing these will break if you serve things that dont have an app.manifest_url (so I think it is a breaking change)

https://github.com/mozilla-b2g/gaia/blob/master/apps/search/js/providers/marketplace.js#L59
Yup, was typing this out as Dale responded, but I think he is correct.

Gaia code in 2.0/2.1 references manifest_url, and it appears there is no guards there =/ It's likely that if we receive a result without manifest_url it will break the display/dedupe logic. We would need to test this though.
Ah, that is unfortunate.  In that case, yeah, we'd need to increment the API version.
(In reply to Wil Clouser [:clouserw] from comment #2)
> Shouldn't this be nominated for 2.2?

I don't think so.  If it's low risk, it'll get in.  If not, then we could live without it if it came down to it.
Flags: needinfo?(pdolanjski)
Could you nom this for 2.2?
Flags: needinfo?(pdolanjski)
This is a late feature request, but it would enable Marketplace to deliver website indexing functionality for 2.2 devices.  I'm nom'ing it to get it on the radar.
blocking-b2g: --- → 2.2?
Flags: needinfo?(pdolanjski)
Shouldn't this be feature-b2g instead? It would be pretty trivial to get this in once we have bug 1129621 finished.

Also another thing we could do here is to quickly clone the v2 to a new v3 endpoint that does not yet return websites. Assuming that we follow the same API contract, we should be able to spin a gaia patch before having website support.
Do we know what non-app results should look like from a UX point of view? Should we just treat them like bookmarks and open them in a browser window? As well as not showing the "install" prefix we need to add the logic to open rather than install them.

I want to point out that in future it's possible we might also want to open rather than install apps with a W3C manifest and/or hosted Open Web Apps. Hopefully that can be treated separately though, perhaps by adding the type property to the API results to distinguish between types of apps.
Flags: needinfo?(fdjabri)
I was thinking about this and was one of the things I wanted to discuss.

Here are the use cases (I think)

a) if 'manifest_url' - offer install button. 
b) if 'url' - launch with chrome control (or possibly full browser). This is like "chrome": { "navigation": true }.  I think this is what happens with e.me today.
c) if 'webpage_with_manifest_link' (or whatever is a better name): launch using info in linked manifest as described in Pinned Apps new webpage manifest, (proposed in https://wiki.mozilla.org/FirefoxOS/Pinned_Apps). If "display:standalone" is present then launch without chrome control, otherwise launch with chrome control.

There is also a case of 'instant apps', which we experimented with, where there is an external manifest url, but the app is launched without installation. 

d) 'manifest_url_but_launch_instead_of_install':  A try, then install.  I am not sure if we should support this in light of (c) above, which I would think would replace this case (but not yet supported or used by anyone today).  So perhaps we should cover this case for now.  Or perhaps this becomes a user setting?

I am also not sure we need to distinguish between a webpage without a manifest (b) and with with a linked manifest (c), since I would think the browser engien could determine this at launch time when the page is loaded if the manifest link is present on the page.

I also think the 'manifest_url'/install option would always be the case for packaged apps - since they don't perform well under the instant app model.

Forgive my ramblings...
The short answer:

(In reply to David Bialer [:dbialer] from comment #13)
> a) if 'manifest_url' - offer install button.

For 2.2, yes.

> b) if 'url' - launch with chrome control (or possibly full browser). This is
> like "chrome": { "navigation": true }.  I think this is what happens with
> e.me today.

EverythingMe results in 2.1 open in a browser window, I think that's what we should do for 'url' results in 2.2. (EverythingMe results don't exist in 2.2).

> c) if 'webpage_with_manifest_link' (or whatever is a better name): launch
> using info in linked manifest as described in Pinned Apps new webpage
> manifest, (proposed in https://wiki.mozilla.org/FirefoxOS/Pinned_Apps). If
> "display:standalone" is present then launch without chrome control,
> otherwise launch with chrome control.

We probably won't support this in 2.2.



The long answer:

Disclaimer: All of my opinions about 3.0 are just my opinions and we currently have no idea what 3.0 is going to look like, so take them with a pinch of salt :)

In 3.0 what I would personally like to see is that all hosted web apps can be launched instantly in a browser window without needing to install them first. Installation or "pinning" would be an optional step the user can take to split the app off from the rest of the web and use it separately from the browser, in the display mode specified in the manifest.

Unfortunately I don't think we can apply a manifest to a browsing context when the user just navigates it to a URL because it represents too much of a phishing risk to allow web sites to hide the URL bar whenever they like. Also each time a browsing context is navigated it wouldn't know which display mode it needed to be in until the page had loaded because it doesn't know when it's entering or leaving the scope of an app and what display mode that app uses until it has detected, downloaded and parsed a manifest. That could make for quite a nauseating user experience. When "browsing" web apps which aren't yet installed the browser chrome provides a safety net to the user so that they always know where they are and can always get back. When the user navigates to page which is part of a web app, the user agent can then inform them of this and give them the option to install or "pin" that app to their device.

I believe applying a manifest to a browsing context to create an application context requires an explicit step from the user to install or "pin" the app to their device from a knowable origin, at which point the app is registered in the app registry as managing a defined URL scope separately from the browser. Only at this point can the manifest safely be applied to a browsing context to create an application context with a different display mode and a clearly defined scope.

I think 'webpage_with_manifest_link' should just be 'manifest_url'. You could technically link to a mozApps manifest from a manifest link relation to make use of our proprietary extensions, though I'm not sure if this is something we'd want to recommend.

> There is also a case of 'instant apps', which we experimented with, where
> there is an external manifest url, but the app is launched without
> installation.
>
> d) 'manifest_url_but_launch_instead_of_install':  A try, then install.  I am
> not sure if we should support this in light of (c) above, which I would
> think would replace this case (but not yet supported or used by anyone
> today).  So perhaps we should cover this case for now.  Or perhaps this
> becomes a user setting?

From 3.0 I would like to see "launch first, install later" to be the default mode of interaction for all hosted web apps. It's not quite true that nobody yet supports W3C web app manifests BTW, there were ~600 uses of it on the web the day after Google announced Chrome support, and I assume it has been growing ever since. Sites like CNet and IRCCloud already use it. Hopefully more will use it if we support it in Firefox too.

> I am also not sure we need to distinguish between a webpage without a
> manifest (b) and with with a linked manifest (c), since I would think the
> browser engien could determine this at launch time when the page is loaded
> if the manifest link is present on the page.

As above, I think you should be able to load all web pages of all web sites and web apps instantly in a browser window, but we should inform the user when the current page is part of an app they can install/pin.

> I also think the 'manifest_url'/install option would always be the case for
> packaged apps - since they don't perform well under the instant app model.

Yes, I don't think we should try to retrofit "instant" to packaged mozApps, we shouldn't try to hide the download and install step from the user in this case. I'm not sure about the case of "hosted packaged apps" which are currently being worked on though.

> Forgive my ramblings...

Trust me, my ramblings are much worse :)
Whiteboard: [systemsfe]
Triage is not blocking because this is not a committed feature in 2.2, unless this is directly tied in to new search providers coming in. Please re-nom if necessary.
blocking-b2g: 2.2? → ---
(In reply to Ben Francis [:benfrancis] from comment #12)
> Do we know what non-app results should look like from a UX point of view?
> Should we just treat them like bookmarks and open them in a browser window?
> As well as not showing the "install" prefix we need to add the logic to open
> rather than install them.
> 

If the non-installable content is a URL, then I agree, we should treat them like bookmarks and open them in the browser in 2.2. Are there other types of content we should worry about for now in 2.2?
Flags: needinfo?(fdjabri) → needinfo?(bfrancis)
Agreed.  

There are other types of installable content - homescreens and langpacks, but I think those should work with the manifest_url.  I don't think we need to do anything special - though would ask a second opinion on this.
I don't think installable things are a problem, we should probably just treat them as apps.

For non-installable things without a manifest URL I think we need to take some action in the search app because currently it will try to show all Marketplace results as installable, and would fail for results which don't specify a manifest URL.

If we want to support this in 2.2 it probably makes sense to display them like bookmarks (I have other suggestions for 3.0) and we need a patch for that and probably need to change the Marketplace API endpoint to a new version to not break old versions of Firefox OS. Given we're nearly at FL now and are short on time, another alternative is to not support this in 2.2 and add it in 3.0 as part of a wider new content model.
Flags: needinfo?(bfrancis)
Can we get this in 2.2?  We will have content in marketplace?
I know it's late.  Is it possible to get this in.  MP will be serving up URLs that can be launched directory as well apps in Q2.
Flags: needinfo?(swilkes)
(In reply to David Bialer [:dbialer] from comment #19)
> Can we get this in 2.2?  We will have content in marketplace?

Before we can get anything in, we would need to have a new API endpoint published as this requires a version update. We would need results to be working at the following URL: https://marketplace.firefox.com/api/v3/apps/search/rocketbar/?q=game

If you want, they can mirror the v2 results until the functionality is there. I'm not sure if this should be tracked in bug 1129621, or if we should create a new bug for this.
I can't speak to whether this can land for 2.2. Think that's more a release management question.
Flags: needinfo?(swilkes)
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.