768946 - Make marketplace app available offline

Status: RESOLVED INVALID

(Firefox OS Graveyard :: Gaia, defect)

Description

[Wil Clouser [:clouserw]]

If someone launches the marketplace app while they are not connected to a network we should show them something.  For this bug, a styled message saying "You must have a data connection to access the marketplace." is fine.  If there is more we want to show at a future date we can make adjustments in a different bug.

Comment 2

[Kumar McMillan [:kumar]]

For anyone working on this, info about the initial appcache support we have thus far is in bug 759563

Comment 3

[Jason Smith [:jsmith]]

Does the implementation also include hooking up preloading of the appcache on web apps install for marketplace? Or should I file a separate bug for that?

Comment 4

[Christopher Van Wiemeersch [:cvan]]

(In reply to Jason Smith [:jsmith] from comment #3)
> Does the implementation also include hooking up preloading of the appcache
> on web apps install for marketplace? Or should I file a separate bug for
> that?

It does. Not to dev: bug 759563 comment 1 is what kumar's talking about.

Comment 5

[Kumar McMillan [:kumar]]

(In reply to Jason Smith [:jsmith] from comment #3)
> Does the implementation also include hooking up preloading of the appcache
> on web apps install for marketplace? Or should I file a separate bug for
> that?

As I understand Gaia, once we add an appcache then it will be preloaded automatically since the Marketplace will be distributed with Gaia.

Comment 6

[Jason Smith [:jsmith]]

(In reply to Kumar McMillan [:kumar] from comment #5)
> (In reply to Jason Smith [:jsmith] from comment #3)
> > Does the implementation also include hooking up preloading of the appcache
> > on web apps install for marketplace? Or should I file a separate bug for
> > that?
> 
> As I understand Gaia, once we add an appcache then it will be preloaded
> automatically since the Marketplace will be distributed with Gaia.

True, but what about other platforms? Desktop and Android?

Comment 7

[Kumar McMillan [:kumar]]

(In reply to Jason Smith [:jsmith] from comment #6)
> True, but what about other platforms? Desktop and Android?

Hmm, I don't know if there is a way to preload an appcache without visiting a site. When the person first visits marketplace on those platforms the appcached resources will start to load. From there on out it will cached.

Comment 8

[Jason Smith [:jsmith]]

(In reply to Kumar McMillan [:kumar] from comment #7)
> (In reply to Jason Smith [:jsmith] from comment #6)
> > True, but what about other platforms? Desktop and Android?
> 
> Hmm, I don't know if there is a way to preload an appcache without visiting
> a site. When the person first visits marketplace on those platforms the
> appcached resources will start to load. From there on out it will cached.

Actually, we just added support for this for desktop, B2G is coming as well (it's actively being implemented and is a basecamp+ blocker). See https://developer.mozilla.org/en/Apps/Manifest for how the appcache_path is used (it's a brand new manifest item you can use).

Comment 9

[Kumar McMillan [:kumar]]

(In reply to Jason Smith [:jsmith] from comment #8)
> Actually, we just added support for this for desktop, B2G is coming as well
> (it's actively being implemented and is a basecamp+ blocker). See
> https://developer.mozilla.org/en/Apps/Manifest for how the appcache_path is
> used (it's a brand new manifest item you can use).

Nice! So we just need to add appcache_path to our manifest. I like that.

Comment 10

[Github Issues Guy]

step one landed!

https://github.com/mozilla/zamboni/commit/27921a0

set USE_APPCACHE = True and ./manage.py build_appcache --settings=settings_local_mkt to get the ball rolling.

Comment 11

[Wil Clouser [:clouserw]]

What's the status of this bug?

Comment 12

[Potch [:potch]]

now that we have no url prefixing for locale, we just need to decide what assets we want in the cache and build a fallback "oops we're offline" page.

Comment 13

[Wil Clouser [:clouserw]]

This bug is only for the placeholder message saying you need to be online.  We can worry about corner cases later on.  Is this a bug for you then?

Comment 14

[Potch [:potch]]

As of present, here's our situation.

As an 'external app' in the parlance of gaia, we can provide an app manifest to be bundled in the product. At present, if that manifest contains an appcache_path property, the offline manifest is not pre-loaded during the build process. I've filed https://github.com/mozilla-b2g/gaia/issues/3492 to track this issue.

ccing bwalker and fabrice on this.

Comment 15

[Potch [:potch]]

https://github.com/mozilla/zamboni/commit/90f70a9

Comment 16

[Potch [:potch]]

*punt*

Comment 17

[Wil Clouser [:clouserw]]

Solving this is a basecamp blocker.  Read https://github.com/mozilla-b2g/gaia/issues/3492 for concerns about appcache.

Comment 18

[Potch [:potch]]

Status update- I opened a gaia pull request with an initial media dump to get them unblocked on writing the build tools to prepopulate the cache.

PR here: https://github.com/mozilla-b2g/gaia/pull/4930

Comment 19

[Christopher Van Wiemeersch [:cvan]]

Is this blocked on anything?

Comment 20

[Jason Smith [:jsmith]]

The design of this bug isn't relevant to blocking ship, mainly cause on-device, we already provide a message if the user doesn't have a connection. The platform issue blocking this from working does block, but not the marketplace portion. Removing nom.

Comment 21

[Wil Clouser [:clouserw]]

Potch, this used to have blocking-basecamp+ but it was removed in comment 20.  Can you explain what is different between now and then?

Comment 22

[Jason Smith [:jsmith]]

(In reply to Wil Clouser [:clouserw] from comment #21)
> Potch, this used to have blocking-basecamp+ but it was removed in comment
> 20.  Can you explain what is different between now and then?

Comment 23

[Jason Smith [:jsmith]]

Given that the work involved here actually involves adding the appcache preloading to Gaia in itself, I'm moving this over to Gaia.

I'll send this through triage, but honestly, I don't think this should block. Gaia provides offline error messages that work fine. The fact we don't get marketplace's specialized error page is a nice to have at best.

Comment 24

[Etienne Segonzac (:etienne)]

We're waiting on the embedded font removal here, but after that we're good to go!

Comment 25

[Potch [:potch]]

Updated -dev, and waiting on the new assets to land there, should have https://github.com/mozilla-b2g/gaia/pull/6738 updated in a few minutes

Comment 26

[Jason Smith [:jsmith]]

Disagree on the blocking call - the appcache benefits here are nice, but if push came to shove, I don't think we hold the release on this.

Comment 27

[Jason Smith [:jsmith]]

Triage - not blocking because the offline appcache benefits here mainly target a specialized offline error page for marketplace. Gaia currently already presents an error page when the user is offline, which is sufficient enough for v1 to go out the door.

We will track it however, given that this was a requirement originally that has good benefits for marketplace.

Comment 28

[Dietrich Ayala (:dietrich)]

First, I disagree that a specialized error page for Marketplace is optional. We'll get input from the product team around the requirement here.


Secondly, we will take patches for this still, since this is a requirement for the Marketplace team IIUC, so just ask for approval for those patches when ready to land.

Comment 29

[Jason Smith [:jsmith]]

(In reply to Dietrich Ayala (:dietrich) from comment #28)
> First, I disagree that a specialized error page for Marketplace is optional.
> We'll get input from the product team around the requirement here.

Why? I just don't see exactly why we would pull the plug on a release if we didn't do this.

If there was more going on here other than an offline error page such as more detailed offline experience, then I think there would be a worthwhile discussion here to analyze. But that's not the case here - a user has clear indication by Gaia generic no network connection error page that would fire if no network connection was detected.

I also don't think the argument of "just because it's listed in the product requirements originally means we should block on it." We're under the gun right now and have to make some tough calls. That includes cutting features if need be.

> 
> 
> Secondly, we will take patches for this still, since this is a requirement
> for the Marketplace team IIUC, so just ask for approval for those patches
> when ready to land.

Well, right. We definitely would still take the patches. I just don't think if push came to shove that we hold a release on this bug.

Comment 30

[Potch [:potch]]

blocking-basecamp has additional meaning- such as the ability to land patches on otherwise heavily frozen branches. Incidentally, the blocking status discussion should be occurring at a stakeholder meeting- we're not going to reach a satisfactory conclusion arguing in here.

Comment 31

[Jason Smith [:jsmith]]

(In reply to Potch [:potch] from comment #30)
> blocking-basecamp has additional meaning- such as the ability to land
> patches on otherwise heavily frozen branches. Incidentally, the blocking
> status discussion should be occurring at a stakeholder meeting- we're not
> going to reach a satisfactory conclusion arguing in here.

It was made at a stakeholder meeting - it was made at triage this morning.

Note as Dietrich stated - if you get approval, you should be able to land this. I have a strong feeling this is a low risk patch, so I don't see why we wouldn't take it.

Comment 32

[Lucas Adamski [:ladamski]]

I agree that this doesn't need to block.  I want all pre-installed apps to be cached for perf reasons but there are existing mitigations: we could packaged them, or they could implement appcache directly and cache themselves on the first load.  The latter is not directly equivalent to preloading but its only a 1-time hit.

Comment 33

[Potch [:potch]]

Based on the ongoing problems we've been facing with bug 815814 and bug 823174 we've decided to focus on other features for the time being. Conceded this should not block.

Comment 34

[Potch [:potch]]

We are shifting focus to a packaged app approach to marketplace, which will solve these needs.

Comment 35

[Jason Smith [:jsmith]]

(In reply to Potch [:potch] from comment #34)
> We are shifting focus to a packaged app approach to marketplace, which will
> solve these needs.

Should we close this bug as no longer valid then?

Comment 36

[Potch [:potch]]

Either that or use this as a tracker for landing the package into gaia. Don't mind either.

Comment 37

[Jason Smith [:jsmith]]

(In reply to Potch [:potch] from comment #36)
> Either that or use this as a tracker for landing the package into gaia.
> Don't mind either.

Let's close then and file a new bug for landing the package into gaia. I do want to talk to you guys more about that package though at some point, however.