Closed Bug 768946 Opened 10 years ago Closed 9 years ago

Make marketplace app available offline

Categories

(Firefox OS Graveyard :: Gaia, defect)

defect
Not set
normal

Tracking

(blocking-basecamp:-, b2g18+)

RESOLVED INVALID
blocking-basecamp -
Tracking Status
b2g18 + ---

People

(Reporter: clouserw, Unassigned)

References

Details

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.
Duplicate of this bug: 759563
For anyone working on this, info about the initial appcache support we have thus far is in bug 759563
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?
blocking-basecamp: --- → ?
blocking-kilimanjaro: --- → ?
(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.
(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.
(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?
(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.
(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).
(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.
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.
blocking-basecamp: ? → ---
blocking-kilimanjaro: ? → ---
What's the status of this bug?
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.
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?
Blocks: 766199
Assignee: nobody → thepotch
Target Milestone: --- → 2012-08-16
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.
Target Milestone: 2012-08-16 → 2012-08-23
*punt*
Target Milestone: 2012-08-23 → 2012-08-30
Target Milestone: 2012-08-30 → 2012-09-06
Solving this is a basecamp blocker.  Read https://github.com/mozilla-b2g/gaia/issues/3492 for concerns about appcache.
Blocks: 782711
No longer blocks: 766199
blocking-basecamp: --- → +
Depends on: 792247
Severity: normal → critical
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
Target Milestone: 2012-09-06 → 2012-09-27
Is this blocked on anything?
Target Milestone: 2012-09-27 → 2012-10-18
Depends on: 796045
Blocks: 799666
No longer blocks: 782711
Whiteboard: [blocked on platform]
Target Milestone: 2012-10-18 → ---
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.
blocking-basecamp: + → ---
Whiteboard: [blocked on platform]
Target Milestone: --- → 2012-11-15
Target Milestone: 2012-11-15 → 2012-11-22
Whiteboard: [3rd-party-preloaded-apps]
Whiteboard: [3rd-party-preloaded-apps]
blocking-basecamp: --- → ?
Potch, this used to have blocking-basecamp+ but it was removed in comment 20.  Can you explain what is different between now and then?
(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?
Component: Consumer Pages → Gaia
Product: Marketplace → Boot2Gecko
Target Milestone: 2012-11-22 → ---
Version: 1.0 → unspecified
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.
We're waiting on the embedded font removal here, but after that we're good to go!
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
blocking-basecamp: ? → +
Target Milestone: --- → B2G C3 (12dec-1jan)
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.
blocking-basecamp: + → ?
Severity: critical → normal
Priority: P1 → --
Target Milestone: B2G C3 (12dec-1jan) → ---
blocking-basecamp: ? → -
tracking-b2g18: --- → +
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.
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.
(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.
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.
(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.
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.
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.
No longer blocks: 799666
We are shifting focus to a packaged app approach to marketplace, which will solve these needs.
Assignee: thepotch → nobody
(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?
Either that or use this as a tracker for landing the package into gaia. Don't mind either.
(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.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.