Closed
Bug 768946
Opened 12 years ago
Closed 12 years ago
Make marketplace app available offline
Categories
(Firefox OS Graveyard :: Gaia, defect)
Firefox OS Graveyard
Gaia
Tracking
(blocking-basecamp:-, 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.
Comment 2•12 years ago
|
||
For anyone working on this, info about the initial appcache support we have thus far is in bug 759563
Comment 3•12 years ago
|
||
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: --- → ?
Comment 4•12 years ago
|
||
(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•12 years ago
|
||
(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•12 years ago
|
||
(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•12 years ago
|
||
(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•12 years ago
|
||
(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•12 years ago
|
||
(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•12 years ago
|
||
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: ? → ---
Reporter | ||
Comment 11•12 years ago
|
||
What's the status of this bug?
Comment 12•12 years ago
|
||
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.
Reporter | ||
Comment 13•12 years ago
|
||
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?
Reporter | ||
Updated•12 years ago
|
Assignee: nobody → thepotch
Target Milestone: --- → 2012-08-16
Comment 14•12 years ago
|
||
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.
Updated•12 years ago
|
Target Milestone: 2012-08-16 → 2012-08-23
Updated•12 years ago
|
Target Milestone: 2012-08-30 → 2012-09-06
Reporter | ||
Comment 17•12 years ago
|
||
Solving this is a basecamp blocker. Read https://github.com/mozilla-b2g/gaia/issues/3492 for concerns about appcache.
Updated•12 years ago
|
Severity: normal → critical
Comment 18•12 years ago
|
||
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
Updated•12 years ago
|
Target Milestone: 2012-09-06 → 2012-09-27
Comment 19•12 years ago
|
||
Is this blocked on anything?
Reporter | ||
Updated•12 years ago
|
Target Milestone: 2012-09-27 → 2012-10-18
Reporter | ||
Updated•12 years ago
|
Comment 20•12 years ago
|
||
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: + → ---
Depends on: 809947
Reporter | ||
Updated•12 years ago
|
Whiteboard: [blocked on platform]
Target Milestone: --- → 2012-11-15
Reporter | ||
Updated•12 years ago
|
Target Milestone: 2012-11-15 → 2012-11-22
Updated•12 years ago
|
Whiteboard: [3rd-party-preloaded-apps]
Updated•12 years ago
|
Whiteboard: [3rd-party-preloaded-apps]
Updated•12 years ago
|
blocking-basecamp: --- → ?
Reporter | ||
Comment 21•12 years ago
|
||
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•12 years ago
|
||
(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
Comment 23•12 years ago
|
||
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•12 years ago
|
||
We're waiting on the embedded font removal here, but after that we're good to go!
Comment 25•12 years ago
|
||
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
Updated•12 years ago
|
blocking-basecamp: ? → +
Target Milestone: --- → B2G C3 (12dec-1jan)
Comment 26•12 years ago
|
||
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: + → ?
Updated•12 years ago
|
Severity: critical → normal
Priority: P1 → --
Target Milestone: B2G C3 (12dec-1jan) → ---
Updated•12 years ago
|
blocking-basecamp: ? → -
tracking-b2g18:
--- → +
Comment 27•12 years ago
|
||
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•12 years ago
|
||
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•12 years ago
|
||
(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•12 years ago
|
||
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•12 years ago
|
||
(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•12 years ago
|
||
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•12 years ago
|
||
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•12 years ago
|
||
We are shifting focus to a packaged app approach to marketplace, which will solve these needs.
Assignee: thepotch → nobody
Comment 35•12 years ago
|
||
(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•12 years ago
|
||
Either that or use this as a tracker for landing the package into gaia. Don't mind either.
Comment 37•12 years ago
|
||
(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: 12 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•